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I.  INTRODUCTION 


This  chapter  discusses  the  Marine  Aviation  Logistics  Squadron  (MALS),  the 
doctrine  for  aviation  logistics,  and  the  information  management  systems  currently  used  to 
accomplish  the  mission.  The  chapter  then  discusses  the  objectives,  expected  benefits, 
methodology,  and  organization  of  the  remaining  chapters  of  this  thesis. 

This  chapter  is  organized  as  follows.  Section  A  is  the  background  infonnation  for 
the  MALS,  the  Marine  Aviation  Logistics  Support  Program  (MALSP)  and  the 
information  management  systems  that  MALS  is  currently  using  to  execute  mission 
requirements.  Section  B  justifies  this  academic  endeavor  by  pointing  out  the  acute 
problems  of  the  current  information  management  systems.  Section  C  discusses  the 
objectives  and  broad  system  requirements  for  the  prototype  to  be  developed;  Section  D 
provides  six  ways  tactical-level  aviation  logistics  will  be  optimized  by  a  web-centric 
application;  Section  E  introduces  the  various  methodologies  used  to  analyze  doctrine,  and 
develop  and  test  the  web-enabled  prototype;  and  Section  F  is  a  brief  description  of  the 
remaining  chapters  of  the  thesis. 

A.  BACKGROUND 

1.  Marine  Aviation  Logistics  Squadron 

United  States  Marine  Corps  Aviation  Logistics  at  the  tactical  level  is  the 
responsibility  of  the  Marine  Aviation  Logistics  Squadron  (MALS).  There  are  1 1  active 
duty  MALS  units  supporting  71  tactical  flying  squadrons  and  28  non- flying  squadrons. 
MALS  directly  supports  the  tactical  flying  squadrons  of  the  Marine  Air  Ground  Task 
Force  (MAGTF),  Air  Combat  Element  (ACE)  by  providing  intermediate-level 
maintenance,  supply  and  ordnance  support  for  aircraft  and  aeronautical  equipment  [1]. 
The  role  of  the  MALS  cannot  be  underestimated;  they  are  the  essential  link  of  Marine 
Aviation  Logistics  support  that  enhances  combat  readiness  of  the  MAGTF  ACE  and 
provides  the  sustainment  necessary  for  continuous  combat  operations. 
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Figure  1.  Levels  of  Aviation  Logistics 

Marine  Aviation  Logistics  Squadrons  vary  in  size,  ranging  between  600-800 
Marines  and  Sailors.  The  organizational  structure  of  MALS  consists  of  Headquarters, 
Maintenance,  Supply,  and  Aviation  Information  Systems  Departments.  Headquarters  is 
similar  to  other  aviation  units  with  having  a  Commanding  Officer,  Executive  Officer, 
Administrative,  Operations,  and  Logistics  Department.  However,  the  focus  of  effort  and 
most  of  the  work  performed  by  MALS  is  done  by  the  Maintenance  and  Aviation  Supply 
Departments. 

The  MALS  Maintenance  Department’s  core  functions  include  repair  support  to 
aircraft,  aviation  support  equipment,  avionics,  flight  equipment,  cryogenics,  aviation 
ordnance,  and  maintenance  data  collection  and  analysis  [1].  As  an  intermediate-level 
maintenance  activity,  MALS  maintenance  is  responsible  for  monitoring  all 
organizational-level  maintenance  programs  of  the  tactical  flying  squadrons  assigned  to 
the  Marine  Aircraft  Group  (MAG).  This  oversight  task  protects  the  quality  assurance  of 
maintenance  practices  and  ultimately  leads  to  increased  combat  readiness. 

The  MALS  Aviation  Supply  Department’s  core  functions  include  the  inventory, 
storage  and  management  of  aviation  logistics  material.  MALS  Supply  is  responsible  for 
providing  technical  research  for  needed  aircraft  repair  parts  and  material,  maintaining  and 
reporting  financial  data  for  aviation  material  for  the  MAG,  and  monitoring,  expediting, 
storing,  issuing,  and  delivering  parts  and  material  that  have  been  requisitioned  [1].  The 
Aviation  Supply  Department  is  a  multi-million  dollar  facility,  organized  to  provide 
focused  logistics  support  to  sustain  combat  operations  of  tactical  flying  squadrons  and  the 
intermediate-level  repair  capability  of  the  MALS  Maintenance  Department. 
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The  MALS  Operations  Department  is  responsible  for  identifying,  planning, 
reviewing,  coordinating  and  supervising  all  tactical-level  aviation  logistics  necessary  to 
support  operational  requirements  for  exercises,  contingencies  and  other  concepts  of 
operations  [1].  To  execute  these  core  functions  and  properly  tailor  support,  continuous 
coordination  is  required  internally  with  the  MALS  Maintenance  and  Supply  Departments. 
Externally,  however,  the  MALS  Operations  Department  is  the  link  between  the  MAG  and 
tactical  flying  squadrons  to  ensure  the  appropriate  level  of  aviation  logistics  support  is 
incorporated  in  all  deliberate,  time  sensitive  and  crisis  action  planning. 

2.  Marine  Aviation  Logistics  Support  Program 

The  Marine  Aviation  Logistics  Support  Program  (MALSP)  is  the  current  doctrine 
used  to  rapidly  deploy  and  sustain  a  task-organized  MAGTF  ACE.  The  MALSP  is  based 
on  people,  repair  parts,  support  equipment  and  mobile  maintenance  facilities.  Together, 
they  form  the  essential  “building  blocks”  for  tailored  aviation  logistics  support. 


People 


Spare/Repair 

Parts 


Support 

Equipment 
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Facilities 


Figure  2.  MALSP  Building  Blocks  [From:  1] 


Each  MALS  is  designed  to  support  Fixed  Wing  (FW)  and/or  Rotary  Wing  (RW) 
aircraft.  However,  mission  requirements  often  require  a  mixed  FW/RW  aircraft 
composition,  which  necessitates  the  use  of  support  capabilities  from  more  than  one 
MALS.  To  facilitate  responsive  and  effective  support  across  various  Type/Model/Series 
(T/M/S)  aircraft,  standardized  Contingency  Support  Packages  (CSP)  are  maintained  at 
each  MALS  consisting  of  a  Common  Contingency  Support  Package  (CCSP),  Peculiar 
Contingency  Support  Package  (PCSP),  Fly-In  Support  Package  (FISP),  Follow-On 
Support  Package  (FOSP)  and  Training  Squadron  Allowance  (TSA).  These 
predetermined  packages  give  the  MAGTF  Commander  the  flexibility  to  mix  and  match 
T/M/S  aircraft  with  the  required  aviation  support. 
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In  the  event  of  a  major  operation  or  contingency  where  a  tailored  ACE  is 
required,  a  host  MALS  is  identified  and  marshals  their  Common  Contingency  Support 
Package.  The  host  MALS  will  also  provide  any  Peculiar  Contingency  Support  Packages 
organic  to  their  MAG  that  matches  the  T/M/S  aircraft  mix  of  the  proposed  ACE.  Non- 
organic  Peculiar  Contingency  Support  Packages,  however,  are  provided  by  another 
MALS.  These  CSPs  are  then  airlifted  or  embarked  on  Aviation  Logistics  Support  Ships 
(T-AVB).  The  U.S.  Maritime  Administration  provides  the  Military  Sealift  Command 
with  two  T-AVBs,  dedicated  to  support  movement  of  aviation  logistics  ashore,  or  to 
establish  a  “floating”  intermediate-level  aviation  logistics  activity  offshore.  The  CCSP  is 
viewed  as  the  foundation  of  support,  while  the  PCSP  is  viewed  as  load-bearing  pillars  of 
the  aviation  logistics  support  structure  [1]. 
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Figure  3. 


MALSP  Employment  [From:  1] 


The  remaining  MALSP  CSPs  are  the  FISP  and  FOSP.  The  FISP  is  reserved  stock 
for  a  time  of  war;  therefore,  it  is  always  maintained  at  or  near  100%  stock  allowances. 
The  FISP  consists  of  spare  parts  that  are  normally  removed  and  replaced  at  the 
organizational  (tactical  flying  squadron)  level.  The  FISP  is  built  to  logistically  sustain 
the  initial  30  days  of  combat  operations;  meaning,  it  is  usually  the  first  building  block  in 
the  theater  of  operations,  airlifted  with  the  initial  assault  aircraft.  The  FOSP,  on  the  other 
hand,  is  usually  the  last  CSP  to  be  deployed.  It  consists  of  the  heavy  machinery  and  other 
large  intermediate-level  support  equipment.  The  FOSP  is  designed  to  logistically  support 
aviation  units  indefinitely. 
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The  MALSP,  as  a  whole,  is  “designed  to  be  mutually  supportive  and  fit  together 
like  blocks  to  form  a  solid  aviation  support  foundation”  [1],  The  doctrine  ensures  that 
when  contingencies  arise,  the  appropriate  level  of  aviation  logistics  support  is  mobilized 
to  support  the  MAGTF  ACE. 

3.  Information  Management  Systems 

Marine  Corps  Aviation  Logistics  requires  the  use  of  numerous  Information 
Management  Systems  to  effectively  manage  the  complexity  of  aviation  operations. 
These  systems  include  the  Naval  Aviation  Logistics  Command  Management  Information 
System  (NALCOMIS),  Shipboard  Uniform  Automated  Data  Processing  System,  Real- 
Time  (SUADPS-RT),  MAGTF  Deployment  Support  System  II  (MDSS-II),  Support 
Equipment  Resources  Management  Infonnation  System  (SERMIS),  Local  Asset 
Management  System  (LAMS),  and  Table  of  Basic  Allowance  (TBA).  Additionally,  the 
Marine  Corps  Total  Force  System  (MCTFS),  a  personnel  administration  system,  manages 
all  personnel  assigned  to  a  unit,  which  are  subsequently  tasked  to  execute  aviation 
logistics  support  operations.  Although  there  is  an  array  of  systems  currently  in  use,  the 
MALS  primarily  uses  five  Information  Management  Systems,  NALCOMIS,  LAMS, 
MCTFS,  TBA  and  MDSS-II,  to  input,  process,  review,  report,  store  technical  data  and  to 
develop  deliberate  operational  plans  for  aviation  support  operations. 

NALCOMIS  is  designed  to  provide  timely  and  accurate  information  for  day-to- 
day  management  of  aeronautical  assets  and  equipment  [1].  The  primary  capabilities  of 
NALCOMIS  for  the  MALS  is  to  requisition  material,  manage  maintenance  actions  and 
administer  to  aviation  supply  assets.  NALCOMIS  includes  10  subsystems:  database 
maintenance,  maintenance  activity,  personnel  management,  configuration  status 
accounting,  asset  management,  local/up-line  reporting,  system  support,  material 
requirement  processing,  data  off-load/on-load  and  technical  publications.  NALCOMIS  is 
used  by  both  Maintenance  and  Supply  Departments  within  the  MALS.  SUADPS-RT,  on 
the  other  hand,  is  purely  an  aviation  supply  application,  which  consists  of  three 
subsystems:  logistics  management,  inventory  management  and  financial  management. 
Both  NALCOMIS  and  SUADPS-RT  systems  interface  to  provide  aviation  logisticians 
with  an  efficient  capability  to  accurately  manage  the  myriad  of  aviation  mission-related 
tasks. 
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LAMS  is  a  standardized  system  for  management  of  support  equipment  at  all  three 
levels  of  naval  aviation  maintenance.  LAMS  enhances  the  control  of  inventory  through 
up-line  reporting  to  SERMIS.  The  system  contains  the  master  database  of  equipment  for 
the  Aviation  Maintenance  Material  Readiness  List  (AMMRL)  program  [1], 

TBA  is  a  database  that  provides  the  initial  outfitting  allowances  for  Marine 
Forces.  This  infonnation  system  manages  the  authorized  material  and  organizational 
property  for  all  Marine  Corps  units.  Specifically  at  the  MALS,  the  TBA  provides  the 
quantities  of  mobile  facilities  the  unit  is  responsible  to  maintain,  but  more  importantly,  it 
establishes  the  pool  of  available  assets  from  which  MALS  can  support  the  MAGTF  ACE. 

MDSS-II  is  the  primary  Information  Management  System  used  for  deliberate 
planning  of  aviation  support  operations  at  the  tactical  level.  Unlike  NALCOMIS  and 
SUADPS-RT,  MDSS-II  is  not  an  aviation  specific  application,  but  a  component  of  a 
larger  Marine  Corps  enterprise  system  called  MAGTF-II.  The  purpose  of  MDSS-II  is  to 
enable  planners  to  develop  force  structure,  tailor  force  lists,  compute  sustainment,  and 
plan  for  lift  requirements  [1].  The  product  of  using  the  MDSS-II  system  is  the  Unit 
Deployment  List  (UDL),  which  consists  of  Time  Phased  Force  Deployment  Data 
(TPFDD).  The  TPFDD  is  the  “who,  what,  when,  and  where”  of  force  coordination. 
Once  MDSS-II  has  produced  the  final  UDL,  the  data  is  sent  to  higher  headquarters  and 
imported  into  the  MAGTF-II  system,  which  manages  and  produces  the  TPFDD  for  the 
entire  spectrum  of  the  Marine  Air  Ground  Task  Force. 

B.  PROBLEMS  WITH  THE  CURRENT  SYSTEMS 

The  Marine  Aviation  Logistics  community  does  not  possess  an  application  to 
effectively  develop  operational  plans  and  sustain  deployed  logistical  support  forces. 
MDSS-II  is  a  non-aviation  specific  application  that  is  efficient  in  documenting  and 
reporting  operational  plans  to  higher  headquarters,  but  not  the  IT  enabler  or  decision 
support  tool  that  is  needed  for  developing  the  key  components  (personal,  parts,  support 
equipment  and  mobile  maintenance  facilities)  of  an  aviation  logistical  support  plan.  The 
problem  is  further  magnified  by  the  fact  that  each  key  component  of  an  aviation  logistical 
support  plan  is  currently  supported  by  a  separate  infonnation  management  system: 
NALCOMIS,  LAMS,  MCTFS  and  TBA. 
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The  lack  of  interoperability  of  currently  fielded  systems  creates  enonnous 
challenges  for  the  tactical-level  aviation  logistics  planner  and  sustainer.  Querying 
multiple  systems  to  source  a  single  operation  or  contingency  is  laborious,  time 
consuming  and  inefficient.  Decision  support  for  sustaining  deployed  forces  is  also 
plagued  by  numerous  manual  processes,  which  increases  the  probability  of  information 
redundancy,  errors,  and  ineffectiveness.  Aviation  logistics  support  is  vital  to  the  combat 
readiness  of  the  MAGTF  ACE.  The  current  “flat-file”  technology  used  to  mitigate  the 
lack  of  system  interoperability  is  not  the  21st  century  solution  for  the  Marine  Aviation 
Logistics  community.  It  is  imperative  that  aviation  logistics  planners  and  sustainers  at 
the  tactical-level  have  a  robust  decision  support  application  to  accomplish  their  mission, 
an  IT  enabler  that  has  the  capability  to  interface  with  existing  fielded  systems. 

C.  OBJECTIVE 

The  objective  of  this  thesis  is  to  develop  a  web-centric  application  for  Marine 
Aviation  Logistics  Squadrons  (MALS)  that  can  be  used  to  bridge  the  technology  gap 
from  the  initial  stages  of  developing  deliberate,  time  sensitive  and  crisis  action  plans  to 
the  culmination  of  the  Unit  Deployment  List  (UDL)  /  Time  Phased  Force  Deployment 
Data  (TPFDD)  documentation  in  the  MDSS-II  system.  The  intent  is  to  design, 
implement  and  test  a  “four-into-one”  user  interface  that  combines  the  data  sets  of  existing 
systems  to  optimize  the  management,  decision  support  and  sustainment  of  aviation 
logistics  operations.  The  design  of  the  prototype  will  incorporate  the  following  broad 
system  requirements: 

•  Concept  of  Operations  (CONOPS)  definition 

•  Course  of  Action  (COA)  definition  and  comparison 

•  Tracking  of  deployed  Personnel,  Repair/Spare  Parts,  Support  Equipment 
and  Mobile  Facilities  readiness 

•  Tracking  of  deployed  aircraft  readiness 

•  Requisition  management 

•  UDL  /  TPFDD  Summary 
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D.  EXPECTED  BENEFITS 

A  web-enabled  application  for  deliberate,  time  sensitive  and  crisis  action  planning 
at  the  tactical  level  will  provide  numerous  benefits  over  current  manual  processes. 
Management  and  decision  support  for  MALS  operations  would  be  optimized  by 
improving  integrity,  consistency,  flexibility,  efficiency,  availability  and  maintainability. 

•  Integrity:  A  web-centric  application  would  provide  a  centralized  point  of 
access  for  internal  planning  transactions  which  will  eliminate  data  redundancy  during 
planning  and  sustainment  cycles.  The  system  would  provide  data  processes  specifically 
tailored  for  Marine  Aviation  Logistics  and  MALSP  concepts,  and  save  valuable  man¬ 
hours  correcting  and/or  updating  source  documents. 

•  Consistency:  A  web-enabled  application  would  provide  an  intuitive  user 
interface  and  a  reliable  format  for  both  internal  and  external  planning  and  sustainment 
coordination  efforts.  Employing  a  standard  web  browser  as  the  database  interface  would 
minimize  the  training  required  for  personnel  to  use  the  application. 

•  Flexibility:  A  web-centric  system  would  be  conducive  for  collaborative 
planning  and  execution  at  work,  planning  conferences,  or  at  remote  sites — anywhere 
internet  access  is  available.  The  application  would  also  take  advantage  of  existing  and 
emerging  wireless  technologies:  PDA,  Pocket  PC,  cell  phone,  and  other  equipment  that 
have  integrated  web  browsers. 

•  Efficiency:  A  real-time  web-centric  system  would  improve  the  planning 
and  decision-making  time  cycles  by  reducing  the  number  of  deployment  meetings  and  the 
use  of  “flat-file”  information  technology.  A  system  of  this  nature  would  improve 
visibility  and  response  times  for  deployment  material  support  requests  and  subsequent 
action  of  material  requirements.  The  system  would  also  improve  data  analysis  by  quickly 
searching  the  database  for  historical  and  current  deployment  data  to  identify  trends  and 
other  relevant  information. 

•  Availability:  A  web-enabled  application  would  provide  reliable,  near  real¬ 
time  information  on  aircraft,  personnel  and  maintenance/supply  support  requirements  for 
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deployed  forces.  A  system  of  this  nature  would  provide  globally  visible  information  and 
take  advantage  of  widely  available  internet  access. 

•  Maintainability:  MALS  (AISD)  currently  has  the  Infonnation 
Technology  architecture  to  employ  and  maintain  a  system  of  this  nature;  no  additional 
personnel  or  hardware  requirements  would  be  required.  The  benefit  of  a  web-enabled 
application  is  that  the  MALS  deployment  and  garrison  Information  Technology  footprint 
would  remain  the  same. 

E.  METHODOLOGY 

The  analysis  of  capabilities  and  constraints  of  MALSP  doctrine  and  the  existing 
Information  Management  Systems  used  to  execute  mission  requirements  was 
accomplished  by  a  literature  review  and  by  formal  surveys  of  current  MALS  Operations 
Officers,  an  authoritative  source  and  lead  planners  for  all  aviation  logistics  support 
operations  at  the  tactical  level.  Aviation  Maintenance  and  Supply  Officers  were  also 
surveyed  due  to  their  vital  role  in  the  execution  and  sustainment  phases  of  aviation 
support  operations. 

The  system  design  methodology  for  developing  the  web-enabled  database  was 
Rapid  Action  Development  (RAD),  a  prototyping  methodology.  Operations  Officers 
from  both  MALS-36  and  MALS-11  were  active  end-user  in  this  thesis  research.  They 
provided  the  necessary  feedback  for  the  prototype  iteration  process.  The  web-enabled 
prototype  was  hosted  on  a  Naval  Postgraduate  School  (NPS)  server  (ebiz.nps.navy.mil), 
which  provided  the  ideal  environment  towards  a  proof  of  concept  for  this  research. 

The  Database  and  Web  Technologies  Lab,  located  at  NPS,  was  used  to  test  and 
analyze  web  interface  usability  features  and  system  functionality  by  performing  a 
usability  experiment.  There  were  many  students  assigned  to  NPS  who  had  Marine 
Aviation  Logistics  backgrounds,  including  Aviation  Supply,  Aviation  Maintenance,  and 
former  MALS  Operations  Officers.  Using  personnel  familiar  with  aviation  logistics 
processes  and  procedures  in  a  lab  environment  was  beneficial  in  identifying  and 
confirming  user  requirements  and  streamlining  usability  features  and  prototype  processes 
to  ultimately  produce  to  an  efficient  and  effective  application  to  plan  and  execute  aviation 
logistics  support  operations. 


9 


F. 


ORGANIZATION  OF  THE  THESIS 


The  remaining  chapters  of  this  thesis  are  organized  as  follows:  Chapter  II 
analyzes  the  strengths  and  weaknesses  of  MALSP  doctrine  and  the  current  initiatives  that 
will  transform  aviation  logistics  to  meet  21st  century  requirements.  An  analysis  of  the 
existing  Information  Management  Systems  used  for  operational  planning  and  sustainment 
is  accomplished  in  Chapter  III.  Chapter  IV  is  focused  on  data  and  logical  process 
modeling  for  the  development  of  the  web-enabled  prototype.  The  development  and 
deployment  of  the  prototype  is  discussed  in  Chapter  V.  Web  interface  usability  features 
tested  in  the  Database  and  Web  Technologies  Lab  are  summarized  in  Chapter  VI.  Lastly, 
Chapter  VIII  discusses  lessons  learned,  conclusions,  and  directions  for  future  research. 
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II.  ANALYSIS  OF  MALSP  DOCTRINE 


This  chapter  analyzes  the  strengths  and  weaknesses  of  MALSP  doctrine  and  the 
current  initiatives  that  will  transform  aviation  logistics  to  meet  21st  century  requirements. 

The  chapter  is  organized  as  follows.  Section  A  describes  why  MALSP  was 
originally  implemented;  Section  B  discusses  the  successes  of  MALSP  since  its  inception; 
Section  C  analyzes  the  historical  shortcomings  of  MALSP  doctrine  and  its  relevancy  to 
today’s  strategic  environment;  and  Section  D  discusses  the  transfonnation  strategy  for 
Marine  Aviation  Logistics  to  respond  to  the  unpredictable  challenges  of  2015  and 
beyond. 

A.  MALSP  DOCTRINE 

Prior  to  1988,  Marine  Aviation  Logistics  (AVLOG)  support  for  the  MAGTF  ACE 
was  an  ad  hoc  process  at  best.  Headquarters  and  Maintenance  Squadrons  (H&MS)  relied 
upon  the  resident  expertise  of  maintenance  and  supply  personnel  to  determine  the  optimal 
composition  of  personnel,  parts,  support  equipment,  and  mobile  facilities  to  support  a 
deployment  or  contingency  [2],  Because  of  varying  degrees  of  experience  within  H&MS 
across  the  Marine  Corps,  an  inconsistent  concept  of  operations  for  logistics  support  was  a 
common  result;  both  shortfalls  and  excess  capabilities  often  coexisted  for  task-organized 
contingencies,  which  ultimately  led  to  reduced  combat  readiness.  These  systemic  issues 
were  addressed  with  the  introduction  of  MALS  and  MALSP  doctrine. 

MALS  and  MALSP  doctrine  was  officially  implemented  in  October  1988  [3]. 
This  transfonnation  included  the  structural  reorganization  of  H&MS  into  MALS,  which 
consolidated  the  responsibility  of  AVLOG  support  at  the  tactical  level  to  one  squadron. 
However,  it  was  MALSP  that  was  the  key  piece  of  the  transformation  process.  The 
introduction  of  new  doctrine  led  to  the  ability  to  rapidly  task-organize  and  execute 
aviation  logistics  support  operations  for  major  theater-level  war  [4]. 

B.  MALSP  SUCCESSES 

For  nearly  20  years,  MALSP  doctrine  has  served  the  aviation  community 
sufficiently.  The  following  is  summary  of  operations  where  MALSP  doctrine  has  been 
used  (and  continues  to  be  used  today)  to  support  MAGTF  ACE  missions: 
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Desert  Shield 

Desert  Storm 

Fiery  Vigil 

(Kuwait) 

(Kuwait) 

(Philippines) 

Provide  Comfort 

Victor  Squared 

Southern  Watch 

(Turkey) 

(Haiti) 

(Iraq) 

Restore  Hope 

Provide  Promise 

Deny  Flight 

(Somalia) 

(Yugoslavia) 

(Bosnia) 

Continue  Hope 

Eyes  of  Mogadishu 

Quick  Draw 

(Somalia) 

(Somalia) 

(Somalia) 

Uphold  Democracy 

Decisive  Endeavor 

Assured  Response 

(Haiti) 

(Bosnia) 

(Liberia) 

Deliberate  Guard 

Silver  Wake 

Deliberate  Forge 

(Bosnia) 

(Albania) 

(Bosnia) 

Allied  Force 

Noble  Anvil 

Avid  Response 

(Kosovo) 

(Kosovo) 

(Turkey) 

Allied  Harbor 

Joint  Guardian 

Stabilize 

(Albania) 

(Kosovo) 

(East  Timor) 

Enduring  Freedom 

Secure  Tomorrow 

Iraqi  Freedom 

(Afghanistan) 

(Haiti) 

(Iraq) 

Table  1.  MALSP  Employment  Since  1988 


The  implementation  of  MALSP  dramatically  improved  AVLOG  support  from  an 
improvised,  makeshift  process  to  a  standardized,  predetermined  contingency  support 
package  concept  that  is  capable  of  supporting  the  multitude  of  missions  Marine  Corps 
Aviation  may  be  tasked  to  execute  [1].  Although  the  “building  block”  doctrine  has 
successfully  supported  combat  sorties,  humanitarian  missions,  enforcing  no-fly  zones  and 
other  MAGTF  operations,  Table  1  above  also  reveals  a  trend.  With  the  exception  of 
Operations  Desert  Storm  and  Iraqi  Freedom,  21st  century  contingencies  are  of  a  smaller 
scale  and  not  the  major  theater-level  engagements  that  MALSP  was  originally  designed 
to  support. 
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C.  MALSP  SHORTCOMINGS 

MALSP  was  developed  in  the  Cold  War  era,  where  major  theater  engagements 
were  the  strategic  focus.  The  Cold  War  has  now  ended,  but  the  doctrine  used  to  support 
the  MAGTF  ACE  has  not  [5].  Since  MALSP  has  been  implemented,  major  theater 
engagements  account  for  just  7%  of  MALSP  utilization  whereas  93%  can  be  considered 
smaller  scale  contingencies. 

Looking  through  the  macro-level  lens,  the  underpinnings  of  MALSP  doctrine  are 
no  longer  an  efficient  option  for  today’s  strategic  environment.  The  proliferation  of 
weapons  of  mass  destruction,  terrorism,  and  the  global  economy  are  all  drivers  of  a  new 
strategic  landscape.  Furthermore,  nations  are  less  likely  to  engage  the  United  States  in 
conventional,  major  theater-level,  operations  due  to  its  overwhelming  military  strength 
and  technological  advantages.  Smaller  scale  contingencies  have  become  the  norm  not  the 
exception;  therefore,  a  doctrinal  shift  is,  once  again,  required  for  Marine  Aviation 
Logistics  to  respond  to  the  full  spectrum  of  events  that  threaten  global  stability  and 
national  interests. 

The  shortcomings  of  MALSP  doctrine  are  also  demonstrated  at  the  micro-level. 
In  1999,  MALS-31,  located  in  Beaufort,  South  Carolina,  was  tasked  to  support  the 
NATO  action  of  stopping  Serbian  military  aggression  against  ethnic  Albanians  in 
Kosovo,  with  the  intent  of  restoring  Kosovo’s  borders  and  promoting  regional  stability. 
The  mission,  Operation  Noble  Anvil,  required  MALS-31  to  deploy  a  tailored  yet  self- 
sustaining  support  package  for  24  F/A-18D  aircraft.  Although  the  task  seemed  well 
suited  to  utilize  MALSP,  logistics  planners  had  significant  hurdles  to  clear  in  order  to 
effectively  support  the  operation. 

Operation  Noble  Anvil  posed  significant  problems  for  logistics  planners  because 
support  from  MPF  and  TAV-B  ships  were  not  planned  to  be  used  for  this  deployment  [2]. 
This  challenged  the  fundamental  assumption  of  MALSP  doctrine  that  calls  for 
contingency  support  packages  to  be  integrated  with  the  capabilities  of  MPF  and  T-AVB 
ships;  the  former  to  provide  essential  pre-positioned  support  equipment  and  ordnance, 
and  the  latter  a  means  of  rapid  and  dedicated  sealift  into  an  area  of  operations. 
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With  these  key  components  unavailable,  MALS-3 1  had  no  choice  but  to  deviate 
from  doctrine.  As  a  result,  they  developed  and  deployed  a  Remote  Expeditionary 
Support  Package  (RESP):  a  stand-alone  support  capability  consisting  of  people,  parts, 
support  equipment  and  mobile  facilities  that  can  sustain  operational  requirements 
independently  [5].  Despite  the  challenges,  MALS-3 1  was  successful  in  maintaining  an 
aircraft  mission  capability  rate  of  92%  [2].  The  development  and  implementation  of  the 
RESP  was  successful,  gained  acceptance,  and  was  formally  integrated  within  MALSP 
doctrine  by  the  publication  of  Aviation  Logistics ,  Marine  Corps  Warfighting  Publication 
3-21.2,  in  October  2002.  Nonetheless,  Operation  Noble  Anvil  is  an  example  where 
MALSP  had  to  be  revised  due  to  its  inefficiency  of  supporting  smaller-scale 
contingencies. 

Another  problem  with  MALSP  doctrine  that  is  rooted  from  a  decades-old 
mentality  is  the  concept  of  having  standardized  and  predetennined  support  packages. 
The  foundational  “building  blocks”  of  MALSP,  the  Peculiar  Contingency  Support 
Package  (PCSP)  and  Common  Contingency  Support  Package  (CCSP),  supports  the 
deployment  and  logistics  requirements  of  entire  squadrons  or  groups  of  squadrons  during 
a  major  theater  war  [5],  Lor  example,  an  L-18  PCSP  is  built  to  support  36  aircraft,  which 
is  equivalent  to  three  squadrons.  Theoretically,  if  all  36  aircraft  deploy,  then  MALSP 
works  as  intended.  However,  if  only  two  squadrons  deploy,  e.g.,  Operation  Noble  Anvil, 
with  a  “standardized  and  predetennined”  PCSP,  then  24  aircraft  undoubtedly  have  a 
robust  logistics  support  package,  but  consequently  the  12  L/A-18  aircraft  that  remain 
behind  in  garrison  have  lost  a  significant  amount  of  supporting  personnel,  parts,  support 
equipment  and  mobile  maintenance  facilities.  All  of  which  significantly  reduce  the 
ability  of  those  12  L/A-18  aircraft  to  continue  to  “train  as  they  would  fight”  and  remain 
combat  ready  in  case  they  are  needed.  Hence,  MALSP  is  not  inherently  flexible  or 
sufficient  to  support  smaller-scale  contingencies  in  its  current  state.  In  light  of  the 
increasing  number  and  variability  of  smaller-scale  contingencies  in  the  21st  century,  the 
Marine  Corps  must  re-focus  it  aviation  logistics  support  concepts  from  “standard-sized” 
packages  to  “right-sized”  packages  [5]. 
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D.  TRANSFORMATION  OF  MARINE  AVIATION  LOGISTICS 

The  shortcomings  of  current  MALSP  doctrine  are  well  documented;  Marine 
Aviation  Logistics  must  respond  more  efficiently  to  the  ever-increasing  and  unpredictable 
missions  of  the  21st  century  [6].  The  current  transfonnation  strategy  that  will  enable 
effective  AVLOG  support  in  the  future  consists  of  three  concepts:  AirSpeed,  MALSP-II, 
and  MALS-Future.  These  concepts  are  an  integrated  and  multi-year  undertaking  that  will 
culminate  with  the  implementation  of  MALS-Future,  a  responsive  and  light-weight 
logistical  support  activity  that  is  capable  of  sustaining  the  MAGTF  ACE’s  warfighting 
requirements  of  2015  and  beyond.  MALS-Future  is  currently  under  research  by  the 
Marine  Corps  Studies  System  with  the  intent  of  proposing  a  new  business  model  and 
structure  for  the  future  of  MALS  squadrons  [7]. 

At  the  core  of  the  cultural  shift  is  the  United  States  Navy’s  new  logistical 
enterprise  philosophy  of  AirSpeed.  This  new  philosophy  is  a  blend  of  proven  business 
tools  including  Theory  of  Constraints  (TOC),  Lean  and  Six  Sigma  [5].  The  purpose  of 
AirSpeed  is  to  optimize  the  performance  of  logistics  practices  and  decision-making  at  all 
levels  of  the  logistics  chain  by  focusing  on  interdependencies,  constraints  and  variability 
of  current  practices.  The  end  result  is  a  new  methodology  of  managing  assets  and  a 
streamlined  logistical  support  system. 

The  AirSpeed  philosophy  is  currently  being  implemented  on  a  limited  basis  and 
has  already  received  some  positive  feedback.  MALS-26,  located  at  New  River,  North 
Carolina,  was  the  first  MALS  squadron  to  put  theory  into  action  in  2004.  Using  the 
components  of  AirSpeed,  MALS-26  noticed  process  improvements  and  increases  in 
efficiency  with  their  maintenance  and  diagnostic  workbenches  [8].  “Theory  of 
Constraints  (TOC)  and  the  focus  on  Lean  is  helping  to  achieve  our  goal... AirSpeed 
improvement  tools  help  to  maintain  and  sustain  our  readiness,”  said  the  Executive  Officer 
from  MALS-26  [8], 

The  next  step  in  the  transfonnation  process  is  MALSP-II,  a  new  aviation  logistics 
doctrine  that  addresses  the  challenges  of  supporting  both  small-scale  contingencies 
abroad  and  remain-behind  elements  at  home.  Agility,  flexibility,  responsiveness, 
adaptability,  sustainability,  and  proactiveness  are  the  benchmark  requirements  for  success 
[5].  The  goal  is  to  move  away  from  the  enonnous  logistical  infrastructure  of  a  forward- 
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deployed  MALS  under  current  MALSP  doctrine.  Area  denial  and  anti-access  in  foreign 
regions,  Expeditionary  Maneuver  Warfare  (EMW)  and  sea-basing  are  all  factors  that 
require  a  lighter  more  agile  logistics  footprint. 

To  accomplish  these  goals,  MALSP-II  will  leverage  AirSpeed  concepts  and 
incorporate  emerging  technologies.  An  essential  concept  of  AirSpeed  that  is  applied  to 
MALSP-II  is  a  system  “buffers.”  The  purpose  of  the  buffer  system  is  to  increase  the 
effectiveness  of  logistical  support  while  reducing  infrastructure  and  resources  [5]. 


Figure  4.  MALSP-II  Concept  of  Buffers  [From:  5] 

Figure  4  above  depicts  the  intended  transformation  from  MALSP  to  MALSP-II 
and  how  the  system  of  buffers  is  utilized  to  shift  from  “pushing”  a  large  “standardized” 
infrastructure  into  a  crisis  region  to  a  series  of  “right-sized”  logistical  support  centers 
capable  of  “pulling”  resources  from  a  geographically  dispersed  supply  chain.  Buffers  are 
identified  and  managed  by  a  stop-light  model,  where  green  represents  sufficient  resources 
on-hand;  yellow  means  resources  have  been  used  and  replenishment  plans  should  be 
initiated;  and  red  means  action  is  now  needed  for  current  and  future  operations. 
Individual  buffer  levels  are  determined  by  the  pattern  of  demand  and  the  time  to  rapidly 
replenish  (TRR)  the  resource. 

Current  MALSP  doctrine  is  constrained  by  Cold-War  assumptions  that  are  no 

longer  relevant.  MALSP-II  is  an  effective  transformation  strategy  to  manage  logistics 

assets  and  reduce  the  footprint  required  for  smaller-scale  contingencies  expected  in  the 
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21st  century.  However,  agility,  flexibility,  responsiveness,  adaptability,  sustainability, 
and  proactiveness  can  only  be  fully  realized  by  effectively  leveraging  Information 
Technology  (IT).  Clearly,  the  visibility  and  timely  flow  of  infonnation  is  critical  to  the 
success  of  MALSP-II.  Concept  of  Operations  (CONOPS)  planning  and  managing 
multiple  buffer  nodes,  consisting  of  personnel,  parts,  support  equipment,  and  mobile 
facilities,  requires  a  robust  IT  enabler. 

This  chapter  analyzed  the  strengths  and  weaknesses  of  MALSP  doctrine  and  the 
current  transformation  initiatives  being  pursued  for  naval  aviation.  Implicit  in  all  past, 
present,  and  future  aviation  logistics  actions  is  the  vital  role  of  information  management 
systems,  which  will  be  discussed  in  Chapter  III. 
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III.  ANALYSIS  OF  THE  INFORMATION  MANAGEMENT 

SYSTEM 

This  chapter  analyzes  the  strengths  and  weaknesses  of  the  MAGTF  Deployment 
Support  System  II  (MDSS-II),  and  quantifies  the  extent  of  the  current  decision  support 
problem  by  analyzing  formal  surveys  distributed  to  aviation  logistics  professionals. 

The  chapter  is  organized  as  follows.  Section  A  describes  the  MDSS-II  system 
and  how  it  is  integrated  within  the  LOGAIS  family  of  systems;  Section  B  analyzes  the 
shortcoming  of  MDSS-II  for  the  aviation  logistics  community  with  regard  to  developing 
logistical  support  plans;  Section  C  is  a  concise  statement  of  the  problem  from  which  this 
thesis  is  conceived;  and  Section  D  discusses  the  quantifiable  evidence  of  the  need  for  a 
robust  decision  support  tool  for  aviation  logistics  planners  and  sustainers. 

A.  MDSS-II 

The  MAGTF  Deployment  Support  System  II  (MDSS-II)  is  the  primary 
Information  Management  System  used  for  deliberate  planning  of  aviation  logistics 
support  operations  at  the  tactical  level.  MDSS-II  is  a  component  of  a  larger  Marine 
Corps  enterprise  system  called  MAGTF-II.  MAGTF-II  interfaces  with  the  Global 
Command  and  Control  System  (GCCS)  and  the  Joint  Operation  Planning  and  Execution 
System  (JOPES),  the  central  Information  Management  System  where  U.S.  military  inter¬ 
service  operational  plans  (OPLANS)  and  operations  orders  (OPORDS)  are  published. 
JOPES  is  an  effective  system  for  providing  the  Joint  Chiefs  of  Staff  (JCS),  Combatant 
Commanders  and  the  U.S.  Transportation  Command  with  the  information  needed  to 
manage  and  support  deployed  forces  [1].  The  following  diagram  depicts  the  Information 
Management  Systems  used  for  Force  Deployment  Planning  and  Execution  (FDP&E) 
from  the  macro-perspective: 
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Figure  5. 


Information  Management  System  Relationships 


The  purpose  of  MDSS-II  is  to  enable  tactical-level  planners  to  develop  force 
structure,  tailor  force  lists,  compute  sustainment  and  plan  for  lift  requirements  [1].  The 
product  of  the  MDSS-II  system  is  the  Unit  Deployment  List  (UDL),  which  is  unit 
specific  Time  Phased  Force  Deployment  Data  (TPFDD)  for  an  operation.  The  TPFDD 
identifies  capabilities;  it  is  the  “who,  what,  when,  and  where”  of  force  coordination.  One 
the  UDL  consolidated  and  reviewed  at  the  squadron  level  is  sent  to  higher  headquarters 
and  imported  into  the  MAGTF-II  system,  which  manages  and  produces  the  TPFDD  for 
the  entire  spectrum  of  the  MAGTF. 

B.  DOCUMENTING  VS.  DEVELOPING  LOGISTICAL  SUPPORT 

From  the  micro-perspective,  MDSS-II  is  an  effective  information  management 
system  for  documenting  capabilities — personnel,  aircraft  parts,  support  equipment,  and 
mobile  facilities — for  a  contingency  or  deployment,  but  not  an  efficient  system  for 
identifying  or  developing  those  capabilities.  MALS  squadrons  do  not  have  an  effective 
decision  support  system  for  identifying,  developing  and  consolidating  CONOPS 
information  for  aviation  logistical  support.  At  the  present  time,  MALS  planners  are 
required  to  query  and  consolidate  data  from  multiple  information  management  systems, 
each  specifically  designed  to  manage  a  single  component  of  the  logistics  support  package 
concept — personnel,  aircraft  spare/repair  parts,  support  equipment,  or  mobile 
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maintenance  facilities.  Moreover,  deliberate,  time  sensitive  and  crisis  action  planning  for 
contingencies,  exercises  and  other  CONOPS,  where  no  previous  support  data  exists,  must 
be  initiated  from  scratch — a  significant  challenge  when  time  limited  and  mission  critical. 
As  a  result,  the  MALS  Operations  (S-3)  and  Logistics  (S-4)  Departments  are  forced  to 
expend  resources  and  valuable  man-hours  manually  developing  and  documenting  the 
aviation  logistics  CONOPS  due  to  the  lack  of  integrated  information  management 
systems.  The  following  figure  depicts  the  current  architecture  of  information 
management  systems  used  to  develop  and  document  aviation  logistics  support  for  an 
operation  or  contingency. 
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People 


Spare/Repair 
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Equipment  ,il 


Mobile 

Facilities 


Document  OPLAN 


Develop  OPLAN 
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Figure  6.  Developing  Versus  Documenting  OPLANS 


C.  PROBLEM  STATEMENT 

No  effective  Information  Management  System  exists  for  developing  deliberate, 
time  sensitive,  or  crisis  action  plans  for  tactical-level  aviation  logistics  support  operations 


that  is  integrated  with  the  LOGAIS  family  of  systems  (MDSS-II/MAGTF-II/JOPES). 
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D.  QUANTIFYING  THE  PROBLEM 


1.  Data  Collection 

To  capture  and  quantify  the  extent  of  the  problem,  surveys  were  distributed  to 
personnel  currently  operating  at  MALS  units  throughout  the  Marine  Corps.  There  were 
eight  respondents  of  the  survey,  which  included  MALS  Operations  Officers,  Aviation 
Maintenance  Officers,  and  Aviation  Supply  Officers.  All  respondents  have  experiences 
in  planning  and  executing  aviation  logistics  support  operations  from  Operation  Desert 
Storm  to  the  current  and  ongoing  Operation  Iraqi  Freedom  and  the  Global  War  on 
Terrorism.  The  following  is  the  data  collected  from  the  formal  survey: 


Figure  7.  Survey  Results:  Software  Used  for  AVLOG  Planning 


Figure  8. 


Survey  Results:  Most  Significant  Software  Used  for  AVLOG  Planning 
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Collaborative  planning  for  exercises,  deployments  or  contingencies  are  normally 
accomplished  by  what  means?  (Select  all  that  apply) 


Figure  9.  Survey  Results:  Methods  of  Collaborative  Planning 

On  a  scale  of  1  to  5  (1  =  Not  Useful,  5  =  Very  Useful),  how  would  you  rate 
the  MDSS-1I  application  for  delibrate,  time  sensitive,  or  crisis  action  planning? 


Figure  10.  Survey  Results:  Rating  of  MDSS-II  for  Planning 


Figure  11.  Survey  Results:  Methods  of  Maintaining  Historical  Records 
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Exercise,  deployment,  and  contingency  material  support  requests  for  MALS  are 
normally  received  by  what  means?  (Select  all  that  apply) 


What  is  the  most  significant  communication  method  currently  used  to  receive  and 
act  upon  material  support  requests  from  exercises,  deployments,  or 
contingencies? 


Figure  13. 


□  MS  Excel 

□  POTS 

□  STU-III 
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■  Iridium 
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□  Other 


Survey  Results:  Most  Significant  Methods  of  Material  Support  Requests 


Exercise  or  deployment  reporting  (aircraft,  requisitions,  personnel  and 
equipment  status)  is  normally  accomplished  by  what  means? 
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Figure  14.  Survey  Results:  Means  of  Deployment  Reporting 
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What  is  the  most  significant  communication  method  currently  used  to  receive 
aircraft,  requisition,  personnel,  and  equipment  status? 


□  MS  Excel 

■  POTS 

□  STU-I1I 

□  SALTS 

■  Iridium 

□  AMRR 
i  1  Other 


Figure  15.  Survey  Results:  Most  Significant  Means  of  Deployment  Reporting 


During  an  exercise  or  deployment,  how  often  (average)  is  the  Operations 
Department  updated  on  aircraft,  requisitions,  personnel  and  equipment  status? 
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Figure  16.  Survey  Results:  Frequency  of  Deployment  Reporting 


Based  on  your  experience  with  current  processes  and  procedures  of  Aviation 

Logistics,  you  would _ that  a  real-time,  web-enabled  application  may  be 

beneficial  for  collaborative  planning  of  deployed  tactical- level  (MALS)  aviation 
logistics  forces. 


Figure  17.  Survey  Results:  Web-Enabled  Application  for  AYLOG  Planning 
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2.  Data  Analysis 

The  MDSS-II  application  is  not  the  robust  Information  Technology  (IT)  enabler 
needed  for  planning  aviation  logistics  support  operations,  only  37%  of  the  respondents 
cited  MDSS-II  as  the  application  that  is  normally  used  by  the  Operations  Department  for 
deliberate,  time  sensitive,  and  crisis  action  planning.  However,  100%  of  the  respondents 
cited  the  “flat-file”  technologies  of  Microsoft  Excel  and  Microsoft  Word  as  the  normal 
applications  used  to  execute  planning  requirements.  MDSS-II  did  not  fair  well  as  a 
collaborative  planning  tool  either:  Microsoft  Excel  (75%),  Microsoft  Word  (75%),  and 
Microsoft  Outlook  (75%)  all  outpaced  MDSS-II  (62%)  as  the  tool  most  commonly  used 
to  accomplish  internal  and  external  collaborative  planning  functions.  The  most 
significant  finding  from  the  fonnal  survey;  however,  is  that  67%  of  respondents  rate  the 
MDSS-II  application  as  a  one  (1)  on  a  sliding  scale  of  one  to  five  (1  to  5),  with  one  (1) 
equaling  “not  useful”  and  five  (5)  equaling  “very  useful.”  From  the  survey,  it  is  clear  that 
MALS  could  benefit  from  the  inherent  value  and  collaborative  nature  of  a  web-enabled 
decision  support  tool. 

The  survey  of  aviation  logistics  professionals  also  revealed  some  current 
inefficiency  related  to  sustaining  deployed  forces.  First,  Microsoft  Excel  (via  Microsoft 
Outlook)  is  the  most  significant  application  for  receiving  aircraft,  requisition,  personnel, 
and  equipment  status  updates  from  deployed  forces.  Second,  Microsoft  Excel  is  by  far 
(75%  of  all  requests)  the  most  common  means  of  receiving  deployment  or  contingency 
material  support  requests  from  deployed  forces.  Third,  Microsoft  Excel  is  second  only  to 
the  official  Aircraft  Material  Readiness  Report  (AMRR)  as  the  means  of  deployment 
reporting,  with  the  former  published  just  once  a  day.  Although  aviation  logistics  planners 
and  sustainers  have  an  array  of  available  software  applications,  none  is  more  vital  to  their 
mission  than  Microsoft  Excel;  75%  of  the  respondents  cited  the  application  as  the  “most 
significant”  software  application  used  for  planning  and  sustaining  purposes. 

Hence,  MALS  Operations  Departments  are  using  Microsoft  Excel  to  mitigate  the 
shortfalls  of  currently  fielded  systems  and  the  lack  of  system  integration.  Although 
Microsoft  Excel  is  a  very  popular  application  with  useful  functionality,  the  problem  with 
using  spreadsheets  as  a  planning  tool  is  that  they  are  inherently  designed  for  personal,  not 
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collaborative,  productivity.  Sharing  of  Microsoft  Excel  files  requires  the  use  of  email  or 
a  shared  network  drive,  which  then  leads  to  the  problem  of  document-version  control 
(data  integrity)  as  more  users  participate  in  the  planning  process.  As  a  result,  scarce  man¬ 
hours  are  expended  updating  the  source  document  for  already  time  sensitive  task. 
Furthermore,  pseudo-centralization  of  a  spreadsheet  on  shared  network  drive  is  not 
sufficient  since  only  one  user  at  a  time  can  modify  the  document.  Multi-user  access  is  a 
requirement  for  efficient  coordination  with  Maintenance,  Supply,  AISD  and  the  Logistics 
Departments. 

Information  redundancy  and  inconsistent  format  is  another  problematic  issue; 
over  time,  planning  multiple  exercises  or  contingencies  results  in  multiple  spreadsheets 
with  no  guarantee  of  a  consistent  format  within  (internal  planning)  MALS,  let  alone 
coordination  that  may  be  required  with  another  MALS  (external  planning). 

The  use  of  “flat-file”  technology  is  not  the  most  conducive  means  for 
collaborative  planning  or  sustaining  deployed  forces.  The  decentralized  nature  of 
spreadsheets  does  not  provide  the  functionality  to  effectively  manage  the  infonnation 
requirements  of  aviation  logistics  planning  and  sustainment  operations.  The  complexity 
of  planning  and  coordination  required  to  properly  execute  current  and  future  MALSP 
doctrine  would  be  better  served  by  implementing  an  information  management  system 
specifically  designed  for  aviation  logistics  support  operations. 

The  requirement  for  such  a  system  was  validated  in  June  2005  at  Marine  Aviation 
Maritime  Pre-Positioning  Force  (MPF)  Pre-Tailoring  Conference.  At  the  conference, 
attended  by  key  Marine  Aviation  logistics  planners  from  throughout  the  Marine  Corps, 
the  future  aviation  logistics  requirements  workgroup  identified  the  need  for  a  robust 
decision-support  tool  for  aviation  logistics  planning.  The  following  is  a  summary  of  the 
discussion  and  recommendations  [9]: 

•  AVLOG  Planners  lack  integrated  planning  tools. 

•  The  lack  of  an  AVLOG  plans-specific  decision  support  tool  does  not 
allow  for  detailed  planning  and  integration  with  the  MAGTF-II/LOGAIS  family  of 
systems. 
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•  MDSS-II  data  is  currently  entered  by  hand. 

•  Deployments  are  seldom  based  upon  a  notional  MAGTF.  Each 
deployment  requires  new  embarkation  data  package,  but  planners  lack  the  tools  to 
quickly  create  new  packages. 

•  MALS  needs  a  decision  support  tool  that  helps  to  source  MDSS-II  by 
extracting  supply,  maintenance,  and  IMRL  data  to  tailor  support  packages. 

Hence,  the  goal  of  this  thesis  is  to  develop  a  web-enabled  prototype  that 
implements  the  support  concepts  of  MALSP-II  and  optimizes  CONOPS  planning  and 
management  capabilities  that  have  been  identified  in  the  survey  and  validated  by  the 
aviation  logistics  planners’  discussion  of  future  requirements.  The  MALS  would 
certainly  gain  from  a  web-enabled  database,  as  evidenced  by  75%  “strongly  agreeing” 
and  25%  “agreeing”  that  a  web-enabled  application  may  be  beneficial  for  collaborative 
planning  and  sustainment  of  deployed  tactical-level  aviation  logistics  forces. 

This  chapter  identified  and  quantified  the  problem  with  developing  aviation 
logistical  support  plans  using  the  current  information  management  systems.  The  analysis 
clearly  established  a  need  for  a  robust  application  for  the  MALS.  The  development  for 
such  an  application  is  discussed  in  Chapter  IV. 
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IV.  ANALYSIS  AND  DESIGN  OF  PROTOTYPE  APPLICATION 


This  chapter  discusses  the  methodology  and  tools  used  to  develop  the  MAPSS 
prototype.  This  chapter  then  presents  the  conceptual  data  and  logical  process  models 
used  to  design  the  web-enabled  application. 

The  chapter  is  organized  as  follows.  Section  A  describes  Rapid  Application 
Development  (RAD)  and  why  this  methodology  was  appropriate  for  an  aviation  logistics 
planning  and  sustainment  application;  Section  B  discusses  the  software  development 
tools  used  for  building  the  prototype;  Section  C  discusses  the  mechanics  of  generic 
conceptual  data  modeling  and  then  illustrates  three  specific  data  models  that  were 
developed  for  the  MAPSS  application;  and  Section  D  discusses  the  importance  of  logical 
process  modeling,  and  then  illustrates  the  infonnation  and  control  flow  diagrams  for  the 
three  system  processes. 

A.  PROTOTYPE  METHODOLOGY 

The  methodology  used  to  develop  the  Marine  Aviation  Planning  and  Sustainment 
System  (MAPSS)  was  Rapid  Application  Development  (RAD),  a  strategy  that 
emphasizes  speed  and  user  involvement  in  the  iterative  development  of  software 
prototypes  [10].  The  RAD  methodology  was  developed  by  Jamie  Martin  in  1991,  which 
is  essentially  a  descendent  of  the  Spiral  Development  Model  developed  by  Barry  Boehm 
in  1986,  which  emphasized  prototyping  as  an  effective  means  of  developing  software 
[11].  RAD  is  an  evolutionary  process:  develop,  test,  refine  system  requirements,  and 
then  repeat  the  process.  Prototypes  are  continuously  developed  until  users  are  satisfied 
that  system  requirements  have  been  successfully  discovered  and  implemented  into  a 
working  system. 

RAD  is  an  appropriate  methodology  for  developing  an  application  for  Marine 
Aviation  Logistics  Squadrons  (MALS).  As  discussed  in  Chapter  II,  Marine  Aviation 
Logistics  is  currently  undergoing  a  transformation  from  MALSP  doctrine  to  MALSP-II. 
As  a  result  of  the  ongoing  transfonnation,  some  system  requirements  for  an  operational 
planning  and  sustainment  system  are  currently  unknown  and  some  known  requirements 
will  inevitably  change  as  the  multiyear  transformation  progresses. 
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In  light  of  current  state  of  the  aviation  logistics  community,  traditional  software 
development  strategies  may  be  inappropriate,  ineffective  and  undoubtedly  expensive. 
RAD,  on  the  other  hand,  is  methodology  that  enables  an  application — an  IT  enabler — to 
be  developed  in  parallel  with  the  current  transformation.  The  iterative  approach  to 
prototyping  allows  known  requirements  to  be  developed  and  tested  and  new  or 
unforeseen  requirements  to  be  included  with  future  implementations  or  spirals  of  the 
prototype.  A  decision  support  prototype  application  for  aviation  logistics  is  a  win-win 
situation  for  MALS;  it  addresses  current  information  technology  needs  and  it  is  flexible 
enough  to  incorporate  MALSP-II  and  MALS-Future  concepts  as  they  are  developed. 

B.  DEVELOPMENT  TOOLS 

Three  tools  were  used  to  develop  the  MAPSS  prototype:  Microsoft  Access  2003, 
Microsoft  Visio  2003,  and  Macromedia  Dreamweaver  MX  2004.  Microsoft  Access  is  a 
powerful  yet  user-friendly  program  for  creating  and  managing  relational  databases  that  is 
used  by  both  home  users  to  create  personal  applications  and  professional  software 
developers  to  create  enterprise-wide  applications.  For  the  purposes  of  this  thesis, 
Microsoft  Access  was  used  to  create  the  back-end  relational  database  for  the  prototype. 

Microsoft  Visio  2003  is  a  computer-aided  software  engineering  (CASE)  tool. 
CASE  tools  are  an  essential  element  in  any  information  systems  development  process; 
they  allow  developers  to  quickly  and  accurately  draw  modeling  diagrams,  create 
prototype  user  interfaces,  perform  system  specification  analysis,  and  even  generate 
executable  code  [12].  Microsoft  Visio  2003  was  used  to  create  the  conceptual  data 
models  and  logical  process  models  for  the  MAPSS  prototype. 

Macromedia  Dreamweaver  MX  2004  is  a  professional  web  development  program. 
This  tool  allows  both  beginners  and  advanced  web-designers  to  create  professional  web 
pages  quickly  and  easily.  The  advantage  Macromedia  Dreamweaver  has  over  other  web 
development  products  is  its  user-friendly  integration  of  advanced  web  development 
technologies  and  functionalities[13].  Dreamweaver  allows  beginners  to  design  pages 
using  the  WYSIWYG  interface  or  advanced  users  to  design  directly  from  code.  The 
intuitiveness  for  the  beginner  yet  the  robust  capability  for  advanced  web  designers  are  a 
rare  combination  in  software.  Dreamwever  MX  2004  was  used  to  create  the  web-based 
front  end,  the  user  interface,  of  the  MAPSS  prototype. 
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C.  CONCEPTUAL  DATA  MODELS 

Data  modeling  is  an  efficient  way  to  document  how  data  is  organized  and  stored 
in  a  relational  database  [10].  There  are  many  different  types  of  data  models  used  by 
developers  to  design  and  analyze  data  to  be  stored  for  an  organization,  each  with  its  own 
specific  notation  and  benefits.  The  type  of  data  model  used  and  level  of  detail  is  a 
product  of  design  methodology,  time  available  to  deliver  the  application,  and  the 
developer’s  preference.  One  thing  is  certain,  however;  data  models  should  always  be  part 
of  the  development  process. 

The  Entity  Relationship  Diagram  (ERD)  was  the  type  of  data  model  used  to 
develop  the  MAPSS  prototype.  ERD  is  a  popular  methodology  for  conceptual  data 
models;  it  is  a  method  that  utilizes  several  notations  to  depict  data  in  terms  of  entities  and 
relationships  [10].  Given  that  the  RAD  methodology  calls  for  speed  and  quick 
development  of  prototypes,  the  level  of  detail  and  analysis  for  the  MAPSS  prototype  was 
intentionally  compressed  and  abbreviated.  Conceptual  data  models  for  the  MAPSS 
prototype  were  developed  in  three  steps:  (1)  context  data  model,  (2)  key-based  data 
model,  and  (3)  fully  attributed  data  model. 

1.  Context  Data  Model 

The  context  data  model  was  the  first  step  of  the  MAPSS  conceptual  data 
modeling  effort.  The  purpose  was  to  identify  the  high-level  entities  and  relationships  for 
the  MAPSS  database.  An  “entity”  is  defined  as  persons,  places,  events,  or  concepts  about 
which  an  organization  chooses  to  record  data  [12].  A  “relationship”  is  a  natural  business 
association  between  one  or  more  entities  [10].  For  example,  MALS,  a  SQUADRON  is 
an  entity,  and  OPERATION,  an  event,  is  also  an  entity,  and  both  are  elements  of  data  that 
must  be  maintained  in  the  database.  Since  SQUADRONS  are  tasked  to  execute 
OPERATIONS,  there  is  a  natural  business  or  doctrinal  “relationship”  between  these 
entities.  In  short,  entities  are  usually  nouns  and  relationships  are  usually  verbs. 

Before  a  context  data  model  can  be  developed;  however,  an  organization  must  be 
examined.  A  discovery  process  is  needed  to  capture  the  relevant  entities  and 
relationships  for  the  system.  This  examination  of  the  organization  can  accomplished  in 
numerous  ways,  such  as  interviews  with  intended  users,  observation  of  the  organization, 
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surveys  and  questionnaires,  review  of  doctrine  or  applicable  laws,  or  an  assessment  of 
current  system  capabilities,  to  name  just  a  few  discovery  methods.  Since  MAPSS  was 
designed  as  a  decision  support  tool  for  operational  planning  and  sustainment,  the 
discovery  process  was  focused  on  the  MALS  Operations  Department  (S-3)  and  their 
functional  requirements  of  developing  Concepts  of  Operation  (CONOPS),  Courses  of 
Action  (COA),  and  sustaining  deployed  forces.  Surveys,  interviews  with  intended  users, 
and  a  review  of  doctrine  were  the  discovery  methods  for  this  thesis  research. 

CONOPS  development  was  one  of  the  central  requirements  for  the  system.  The 
key  entities  identified  were  operation,  squadron,  aircraft,  and  course  of  action.  These 
entities  are  related  in  that  operations  are  normally  supported  by  squadrons,  aircraft,  and 
should  have  multiple  courses  of  action  planned  to  execute  the  operation.  In  addition  to 
the  above  requirements,  a  logbook  and  a  782-gear  list  are  two  entities  that  should  be 
maintained  (albeit  not  essential)  for  an  operation.  There  are  benefits  to  documenting 
chronological  events,  as  well  as  maintaining  a  list  of  items  that  personnel  are  required  to 
deploy  with. 

Course  of  Action  (COA)  development  was  another  primary  consideration  for  the 
prototype.  In  fact,  COA  development  is  mandated  by  the  Marine  Corps  Planning  Process 
(MCPP).  Developing  a  COA  for  aviation  logistics  support  requires  planners  to  consider 
multiple  variables.  According  to  aviation  logistics  doctrine,  a  COA  normally  consist  of 
personnel,  repair  parts,  support  equipment  and  mobile  maintenance  facilities.  As 
mentioned  in  Chapter  I,  these  entities  are  the  basic  “building  blocks”  for  aviation  logistics 
support.  Hence,  COA  development  is  centered  on  the  assignment  of  these  entities. 

COA  development  also  has  natural  relationships  to  other  concepts,  places  and 
events,  such  as  tasks,  locations,  vehicles,  and  host  nation  support.  Tasks  are  the  (what) 
actions  that  need  to  accomplished  prior  and  during  COA  selection  and  execution. 
Deployment  locations  (where)  and  vehicles  (how)  are  key  entities  that  should  be 
maintained  and  used  to  differentiate  and  facilitate  COA  selection.  Moreover,  host  nation 
support  is  an  essential  concept  that  must  accounted  for;  it  determines  the  services  and 
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other  support  that  will  be  provided  to  deployed  forces,  which  reduces  the  logistical 
footprint,  saves  resources,  and  aids  planners  in  tailoring  support  packages  that  will  meet 
mission  objectives. 

The  last  area  of  discovery  for  the  decision  support  system  was  operational 
sustainment.  This  requirement  primarily  involves  the  situational  awareness  and  reporting 
requirements  of  the  previously  mentioned  entities:  operation,  aircraft,  squadron, 
personnel,  repair  parts,  support  equipment,  and  mobile  facilities.  Situational  awareness 
and  near  real-time  operational  visibility  are  key  ingredients  to  effective  leadership  and 
timely  decisions. 

Requisition  management  was  also  considered  a  vital  concept  to  operational 
sustainment.  The  mission  of  the  MALS  is  to  maintain  the  combat  readiness  of  the 
MAGTF  ACE,  and  readiness  is  maintained  by  providing  aircraft  with  the  repair  parts  and 
maintenance  actions  they  need  to  continue  flying  combat  missions.  Hence,  an  effective 
decision  support  tool  must  include  the  ability  to  initiate,  update,  complete,  and  track 
requisitions  for  aeronautical  equipment. 

The  discovery  process  provided  the  means  to  identity  the  high-level  entities  and 
relationships  that  were  used  to  start  the  MAPSS  database  development  cycle.  The 
following  figure  depicts  the  context  data  model  for  the  MAPSS  prototype  that  provided 
the  base  from  which  the  key-based  and  fully  attributed  data  models  were  developed. 


Figure  18.  Context  Data  Model 
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2.  Key-based  Data  Model 

The  key-based  data  model  was  the  second  step  in  the  database  design  process. 
The  purpose  of  this  step  was  to  further  develop  entities  and  relationships  by  documenting 
cardinality,  an  important  step  in  the  physical  representation  of  the  database.  The  term 
“cardinality”  is  defined  as  the  minimum  and  maximum  number  of  occurrences  of  one 
entity  that  may  be  related  to  a  single  occurrence  of  the  other  entity  [10].  The  following 
figure  illustrates  the  most  common  cardinality  notation  and  its  interpretation. 
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Figure  19.  Information  Engineering  Cardinality  Notation  [From:  10] 

Primary  keys  and  foreign  keys  are  important  concepts  to  understand  and  essential 
to  proper  implementation  of  a  relational  database.  A  “primary  key”  is  an  attribute  or  a 
group  of  attributes  that  assumes  a  unique  value  for  each  entity  instance  [10].  A  “foreign 
key”  is  a  primary  key  of  an  entity  that  is  used  in  another  entity  to  identify  instances  of  a 
relationship  [12].  An  example  is  the  most  effective  way  to  demonstrate  primary  and 
foreign  key  concepts. 
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Figure  20.  Primary  and  Foreign  Key  Example 


HMM-265,  located  in  Okinawa,  Japan  would  be  single  instance  of  the 
SQUADRON  entity.  The  primary  key  (PK)  for  the  SQUADRON  entity  (data  relating  to 
the  single  instance  of  HMM-265)  could  be  the  Unit  Identification  Code  (UIC).  The  UIC 
is  a  good  candidate  for  a  primary  key  because  it  uniquely  identifies  HMM-265  from  all 
other  squadrons  in  the  Marine  Corps  and  the  value  will  never  change.  Moreover,  a  single 
CH-46E  helicopter  would  be  an  instance  of  the  AIRCRAFT  entity.  The  primary  key  for 
the  AIRCRAFT  entity  (data  relating  to  the  single  instance  of  a  helicopter)  could  be  the 
Bureau  Number  (BUNO).  The  BUNO  is  a  good  candidate  for  a  primary  key  because  it 
uniquely  identifies  a  specific  aircraft  and  the  value  is  pennanently  assigned  and  will  not 
change.  From  Figure  20,  UIC  is  also  a  foreign  key  (FK)  for  the  AIRCRAFT  entity, 
which  indicates  a  business  rule  or  relationship.  Hence,  the  graphical  notation  above  is 
interpreted  as  a  SQUADRON  may  (optional)  have  one-to-many  AIRCRAFT  assigned 
and  an  AIRCRAFT  must  be  assigned  (required)  to  only  one  SQUADRON.  Key-based 
models  are  a  quick  and  an  efficient  tool  for  developing  relational  databases. 


There  is  one  more  aspect  of  key-based  models  that  needs  to  be  discussed:  many- 
to-many  relationships.  When  designing  relational  databases,  many-to-many  relationships 
must  be  treated  differently  than  other  relationships.  Developers  using  Microsoft  Access 
2003  cannot  directly  define  many-to-many  relationships;  therefore,  they  must  add  a  join 
or  junction  entity  and  relate  the  two  entities  using  two  one-to-many  relationships  [14]. 
The  following  figure  demonstrates  the  concept. 
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Figure  2 1 .  Many-to  Many  Relationship  Example 
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Although  the  “real-world”  relationship  is  one  where  a  SQUADRON  may  be 
tasked  to  execute  many  OPERATIONS,  and  an  OPERATION  may  be  executed  by  many 
SQUADRONS,  the  logical  relationship  for  a  relational  database  requires  the  introduction 
of  the  JoinSqdnOp  entity  with  two  one-to  many  relationships  and  the  foreign  keys  from 


the  SQUADRON  and  OPERATION  entities.  The  following  figure  is  the  key-based  data 
model  for  the  entire  MAPSS  prototype. 


Figure  22.  Key-based  Data  Model 
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3.  Fully  Attributed  Data  Model 

The  last  step  in  the  MAPSS  conceptual  data  modeling  process  was  the  fully 
attributed  data  model.  In  addition  to  documenting  all  attributes  for  the  entities, 
nonnalization  was  perfonned.  The  term  “attribute”  is  defined  as  a  descriptive  property  or 
characteristic  of  an  entity  [10].  For  example,  last  name,  first  name,  height,  weight,  blood 
type,  etc.,  are  attributes  for  the  entity  PERSONNEL.  “Normalization”  is  defined  as  a 
data  analysis  technique  that  organizes  data  into  groups  to  form  non-redundant,  stable, 
flexible,  and  adaptive  entities  [10].  The  following  figure  depicts  the  fully  attributed  and 
nonnalized  data  model  for  the  MAPSS  prototype. 
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Figure  23.  Fully  Attribute  Data  Model 
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D.  PROCESS  MODELS 


Process  models  differ  from  data  models.  Although  the  purpose  of  both  is  to 
represent  a  view  of  reality,  a  process  model  has  the  distinction  of  describing  the  system 
processes,  whereas  a  data  model  represents  the  data  needed  by  these  processes.  Process 
models  are  graphical  representations  of  what  the  application  was  designed  to  accomplish. 
Process  models  are  independent  of  data  models  in  that  process  models  depict  what  the 
user  of  the  system  will  see  and/or  execute,  while  data  models  are  usually  transparent  to 
intended  users  and  used  solely  by  developers  to  design  and  accurately  develop  the  back¬ 
end  of  the  system — the  relational  database. 

1.  System  Requirements 

Process  models  should  be  directly  related  to  systems  requirements.  Since  process 
models  describe  what  the  system  will  do,  developers  must  design  the  application’s 
processes  with  system  requirements  in  mind.  As  discussed  in  Chapter  I  of  this  thesis,  the 
intent  of  the  MAPSS  prototype  is  to  be  a  robust  application  for  AVLOG  planners, 
enabling  them  to  develop  deliberate,  time  sensitive  and  crisis  action  plans  and  sustain 
tactical-level  aviation  logistics  support  operations.  To  accomplish  this  purpose,  the 
MAPSS  prototype  was  logically  designed  into  three  functional  modules:  (1)  Concept  of 
Operation  (CONOPS)  Development,  (2)  Course  of  Action  (COA)  Development,  and  (3) 
Operation  Sustainment  Dashboard.  System  requirements  for  each  module  were  identified 
and  validated  by  current  doctrine,  formal  surveys  and  interviews  with  intended  users  of 
the  system.  The  following  system  requirements  were  implemented  into  the  first  version 
of  the  prototype. 

a.  Concept  of  Operations  Development 

(1)  Users  shall  initiate  Concept  of  Operation  (CONOPS)  for  aviation 
logistics  support  for  Current  and  Future  Operations,  which  includes  assigning  squadrons 
and  aircraft  to  an  Operation  based  on  mission  analysis  and  higher  headquarters’ 

Operation  Order  (OPORD). 

(2)  Users  may/shall  initiate  multiple  Courses  of  Action  (COA)  options 
for  the  Commanding  Officer’s  decision.  Types  of  COA  options  shall  include  Forwarding 
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Operating  Bases  (FOB),  Enroute  Support  Bases  (ESB),  Sea  bases.  Ammunition  Supply 
Points  (ASP),  and  Forward  Arming  and  Refueling  Points  (FARP). 

(3)  COA  options  shall  be  summarized  by  type  of  COA,  weight  (tons), 
footprint  (square-feet),  and  occupying  space  (cubic-feet)  to  aid  COA  selection  by  the 
Commanding  Officer  and  the  development  of  Unit  Deployment  List  (UDL)  /  Time 
Phased  Force  Deployment  Data  by  the  squadron  Logistics  Department. 

b.  Course  of  Action  Development 

(1)  Users  may/shall  assign,  update,  and  remove  personnel,  spare  parts, 
support  equipment,  and  mobile  facilities  from  any  COA  option  defined  for  an  Operation. 

(2)  Users  may/shall  document,  update,  and  remove  location 
information  for  any  COA  option  defined  for  an  Operation. 

(3)  Users  may/shall  document,  update,  and  remove  transportation 
information  for  any  COA  option  defined  for  an  Operation. 

(4)  Users  may/shall  document,  update,  and  remove  host  nation  or  unit 
support  infonnation  for  any  COA  option  defined  for  an  Operation. 

(5)  Users  may/shall  document,  update,  and  remove  COA  specific 
planning  and  execution  tasks  for  any  COA  option  defined  for  an  Operation. 

c.  Operation  Sustainment  Dashboard 

(1)  Users  shall  view  readiness  statistics  for  personnel,  repair  parts, 
support  equipment,  and  mobile  facilities  assigned  to  an  Operation/COA  for  the  purpose 
of  aiding  logistics  support  replenishment  decisions. 

(2)  Users  shall  view  readiness  statistics  for  aircraft  assigned  to  an 
Operation  for  the  purpose  of  aiding  logistics  support  decisions. 

(3)  Users  shall  initiate,  update,  and  remove  aeronautical  material 
requisitions  for  aircraft  assigned  to  an  Operation  for  the  purpose  of  requisition 
management. 

(4)  Users  shall  view  detailed  UDL  information  (weight,  footprint,  and 
occupying  space)  for  each  COA  in  order  to  aid  UDL/TDFDD  development  by  the 
Logistics  Department. 
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2.  Information  and  Control  Flow  Diagrams 

There  are  many  different  methods  of  modeling  the  logical  processes  of  an 
information  management  system.  One  effective  method  for  database  driven,  dynamic 
web-enabled  applications  is  the  Information  and  Control  Flow  Diagram.  The  purpose  of 
an  infonnation  and  control  flow  diagram  is  to  depict  the  control  and  information  flow 
within  a  system.  The  MAPSS  prototype  was  developed  using  information  and  control 
flow  diagrams  and  used  the  following  notation:  rectangular  shapes  represent  web  pages; 
dash-lined  arrows  represent  system  control,  i.e.,  hyperlinks,  buttons,  and/or  icons  that 
users  may  select;  and  solid-lined  arrows  represent  the  flow  of  information  in  relation  to 
the  back-end  relational  database. 

a.  MAPSS  User  Log-on  Process 

The  MAPSS  log-on  page  allows  the  user  to  log-on  to  the  system.  Users  are 
required  to  enter  a  username  and  password.  Both  username  and  passwords  are  processed 
and  checked  against  a  user  list  in  the  MAPSS  database.  Upon  successful  authentication, 
users  are  automatically  directed  to  the  “start”  page  of  the  application.  Users  who  are  not 
authenticated  are  presented  with  a  system  feedback  page,  stating  that  either  their 
username  or  password  is  invalid  and  then  given  another  opportunity  to  enter  a  correct 
username  and  password. 

The  MAPSS  “start”  page  has  three  options  for  users  to  select:  Current 
Operations,  Future  Operations,  and  Past  Operations.  The  current  and  future  options 
allow  users  to  access  planning  and  sustainment  functionality  for  active  and  near-future 
operations  that  the  MALS  is  currently  planning,  has  planned  previously,  or  currently  in 
the  process  of  sustaining.  The  Past  Operation  selection  is  for  inactive  or  completed 
operations.  Maintaining  historical  records  is  a  significant  aspect  of  the  MAPSS 
prototype;  it  provides  a  means  to  identify  and  analyze  logistical  trends  that  could  benefit 
current  and  future  planning  requirements.  Regardless  of  the  option  selected,  however, 
system  functionality  and  user  interface  remains  consistent  for  all  (current,  future,  or  past) 
options.  Figure  24  illustrates  the  log-on  process. 
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Figure  24.  User  Log-on  Process 


b.  Concept  of  Operations  Development  Process 

The  Concept  of  Operations  (CONOPS)  development  page  is  the  first  of 
three  MAPSS  processes.  Defining  the  overarching  CONOPS  for  a  contingency  or 
operation  is  a  result  of  mission  analysis  and  guidance  from  higher  headquarters  [15].  The 
primary  purpose  of  the  CONOPS  development  page  is  to  allow  AVLOG  planners  to 
assign  squadrons,  aircraft,  and  establish  alternative  Courses  of  Action  (COA)  options  for 
the  MALS  Commanding  Officer’s  decision.  The  CONOPS  development  page  provides 
the  interface  to  the  other  two  processes  of  the  system:  COA  Development  and  Operation 
Sustainment  Dashboard. 

Additionally,  the  CONOPS  development  page  allows  users  to  establish 
and  maintain  an  Operation  Logbook  and  782  Gear  List.  The  Operation  Logbook  is  a 
function  that  allows  users,  planners,  and  decision-makers  to  chronologically  document,  in 
a  central  and  globally  visible  location,  the  significant  events  of  an  operation  throughout 
the  planning,  execution  and  sustainment  phases.  The  782  Gear  List,  although  not  as 
critical  as  the  Operation  Logbook,  provides  the  means  for  users  (especially  personnel 
assigned  to  an  operation)  to  quickly  discover  what  personal  and  professional  items  they 
are  required  to  have  in  their  possession  when  they  deploy  for  the  operation. 

The  CONOPS  development  page  was  developed  with  robust  functionality. 
In  addition  to  assigning  and  removing  squadrons,  aircraft,  and  alternative  COAs  to  and 
from  an  operation,  users  have  the  capability  to  add,  update  and  delete  information  for  an 
Operation,  Squadron,  Aircraft,  COA,  782  Gear,  and  Logbook  Entry.  Although  these  are 
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basic  database  functionalities  as  a  stand-alone  system,  they  become  more  robust; 
however,  as  system  interoperability  is  incorporated  with  future  versions  of  the  MAPSS 
prototype.  For  example,  Squadron  and  Aircraft  information  would  be  “pulled”  from  the 
NALCOMIS  system,  allowing  drop-down  menus  to  be  populated  for  the  CONOPS 
development/assignment  functionality  within  MAPSS.  Conversely,  MAPSS  was 
developed  with  the  intent  to  have  any  added,  updated,  or  deleted  Squadron  and  Aircraft 
data  “pushed”  to  the  other  interoperable  systems,  in  this  example  the  NALCOMIS 
system. 

System  feedback  is  another  important  functionality.  Since  MAPSS  is  a 
web-centric  transaction-based  system,  users  must  know  the  status  of  transactions;  there 
must  be  timely  reactions  to  all  user  actions  [16].  MAPSS  offers  concise  and  informative 
confirmation  for  all  transactions.  “Success”  pages  notify  users  that  they  have 
successfully  assigned,  removed,  added,  updated,  or  deleted  data  from  the  system. 
Moreover,  a  hyperlink  is  provided  on  each  “success”  page  so  users  can  quickly  conduct 
another  transaction  of  the  same  type  or  return  to  the  parent  process.  Figure  25  illustrates 
the  CONOPS  development  process. 


Figure  25.  Concept  of  Operation  Development  Process 
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c. 


Course  of  Action  Development  Process 


The  Course  of  Action  (COA)  development  process  is  the  second  of  three 
MAPSS  processes,  and  is  the  core  capability  of  the  MAPSS  prototype.  The  COA 
development  process  is  an  essential  and  required  step  in  the  Marine  Corps  Planning 
Process  (MCPP);  the  intent  is  to  generate  multiple  options  that  will  satisfy  mission 
requirements  and  support  the  overall  scheme  of  maneuver  of  the  MAGTF  Commander 
[17].  The  purpose  of  the  MAPSS  COA  development  process  is  to  support  the  decision¬ 
making  process  of  the  MALS  Commanding  Officer  by  rapidly  and  efficiently  generating 
suitable  and  sustainable  aviation  logistics  support  packages. 

As  mentioned  in  Chapter  I,  the  foundation  of  all  aviation  logistics  support 
is  personnel,  repair  parts,  support  equipment,  and  mobile  maintenance  facilities.  Thus, 
MAPSS  COA  development  is  centered  on  the  assignment  and  comparison  of  those 
entities.  The  COA  Development  page  is  designed  to  display  all  currently  assigned 
personnel,  repair  parts,  support  equipment,  and  mobile  facilities  for  the  operation. 
Consistent  with  the  design  and  purpose  of  the  other  MAPSS  processes,  the  COA 
development  page  also  has  remove,  add,  update,  and  delete  functionality  for  personnel, 
repair  parts,  support  equipment,  and  mobile  facility  infonnation. 

Implicit  in  the  development  of  any  COA  is  its  distinguishable  elements  or 
aspects  that  make  one  option  different  or  superior  over  another  given  certain 
circumstances.  Such  circumstances  may  include  logistical  footprint  constraints,  limited 
available  transportation  in  theater,  time  phasing  requirements  for  deployment  and 
execution,  or  host  nation  support,  to  name  a  few.  The  MAPSS  COA  development 
process  was  designed  to  allow  the  AVLOG  planner  the  ability  build  robust  and 
distinguishable  COA  options.  Functionality  includes  the  ability  to  assign  notional  host 
nation  support,  transportation  to  and  from  points  of  embarkation  and  disembarkation, 
multiple  deployment  locations,  and  an  array  of  mission-specific  execution  tasks. 
Effective  COA  development  and  comparison  is  also  hastened  by  aviation  logistics 
support  package  metrics:  weight,  square-feet,  and  cubic-feet  of  each  proposed  COA.  The 
COA  development  page  is  a  concise  yet  infonnation  rich  virtual  workspace  that  allows 
AVLOG  planners  to  introduce  as  many  variables  as  necessary  to  develop  an  array  of 
distinguishable  aviation  logistics  support  packages.  This  capability  can  only  benefit  the 
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effectiveness  of  aviation  logistics  planning  and  the  subsequent  decision  by  the  MALS 
Commanding  Officer.  Figure  26  depicts  the  logical  processes  of  the  MAPSS  COA 
development. 
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Figure  26.  Course  of  Action  Development  Process 

d.  Operation  Sustainment  Process 

Developing  and  approving  plans  are  only  half  of  the  equation.  Executing 
and  sustaining  deployed  forces  is  vital  to  mission  accomplishment.  History  is  stocked 
full  of  examples  where  efficient  and  responsive  logistical  support  was  the  difference 
between  success  and  failure  of  a  military  campaign.  The  current  environment  of  smaller 
scale  contingencies,  asymmetric  warfare  and  distributed  inter  and  intra-theater  bases 
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compound  the  challenges  of  effectively  sustaining  friendly-forces.  Today’s  leaders  and 
aviation  logistics  professionals  need  a  robust  decision  support  tool  for  today’s  complex 
sustainment  requirements. 

The  MAPSS  Operation  Sustainment  process,  referred  to  as  the  “Operation 
Dashboard,”  was  designed  to  provide  the  leaders  at  the  MALS  level  with  the  visibility  to 
synchronize  with  deployed  forces,  the  ability  project  future  requirements  and  the 
functionality  to  actively  engage  in  logistical  sustainment.  The  Operation  Dashboard 
employs  a  stoplight  model,  giving  users  near  real-time  visibility  on  the  status  of 
personnel,  repair  parts,  support  equipment,  mobile  facilities,  and  aircraft.  The  watch 
(green),  plan  (yellow),  and  act  (red)  model  was  designed  to  allow  users  to  quickly 
identify  potential  problems  and  prioritize  any  subsequent  action,  which  saves  time  and 
valuable  resources. 

The  MAPSS  stoplight  decision  aid  is  based  on  mission  capability 
percentages.  For  example,  if  a  COA  has  a  total  of  100  personnel  assigned  and  10 
personnel  are  currently  ill,  injured,  or  unable  to  perfonn  their  duties,  then  the  mission 
capability  for  Personnel  at  that  location  is  currently  90%.  Based  upon  pre-detennined 
criteria  set  for  the  operation,  90%  mission  capability  could  be  a  green,  yellow,  or  red  light 
situation,  requiring  either  no  action  at  all  or  immediate  attention.  Regardless  of  the 
criteria  set  by  the  organization,  leaders  will  quickly  and  accurately  know  the  status  of 
deployed  forces  and  equipment,  a  major  improvement  over  current  manual  processes. 
The  mission  capability  percentages  are  derived  from  data  maintained  in  the  MAPSS 
relational  database.  For  personnel,  repair  parts,  support  equipment,  and  mobile  facilities, 
“current  status”  is  documented  upon  assignment  to  a  COA  and  updated  as  required 
throughout  the  operation,  a  function  that  is  provided  on  the  Operation  Dashboard 
interface.  Aircraft  mission  capability  percentages,  on  the  other  hand,  are  more  complex 
and  derived  from  the  Aircraft  Material  Readiness  Report  (AMRR). 

The  combat  readiness  of  the  MAGTF  ACE  and  the  sustainment  necessary 
for  continuous  combat  operations  is  the  MALS  mission.  Thus,  the  AMRR  is  the  key 
readiness  indicator  for  a  MAGTF  ACE  and  is  often  regarded  as  the  MALS’  report  card 
for  an  operation.  The  purpose  of  the  AMRR  is  record  the  material  support  requirements 
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that  are  currently  on  order  preventing  an  aircraft  from  full  mission  capability  status.  The 
AMRR  includes  infonnation  about  the  aircraft,  the  part  ordered,  and  the  current  status  of 
the  requisition  in  the  logistics  supply  chain.  The  MAPSS  AMRR  functionality  allows 
users  to  quickly  add,  update,  and  delete  requisition  data,  which  in  turn  is  reflected  in 
updated  aircraft  mission  capability  readiness  percentages  and  the  stoplight  indicators. 
MAPSS  provides  extensive  requisition  management  features,  allowing  users,  regardless 
of  time  and  space,  to  actively  engage  in  the  logistical  sustainment  of  deployed  forces. 
This  web-enabled  interface  is  dramatic  departure  from  the  current  redundant  and 
ineffective  “flat-file”  technology  processes  used  to  sustain  aviation  logistics  forces. 

In  addition  to  identifying  what  the  potential  issues  are,  the  Operation 
Dashboard  includes  reports  that  explain  why,  providing  more  in  depth  information  on 
each  component  of  an  operation.  Continuing  the  above  example,  a  Personnel  Report 
would  identify  all  non-mission  capable  personnel  by  name,  military  occupational 
specialty,  social  security  number,  and  reason  for  their  current  status.  Detailed  reports  are 
enabled  for  personnel,  repair  parts,  support  equipment,  mobile  facilities,  and  aircraft;  an 
executive  summary  is  also  available.  Moreover,  MAPSS  reports  are  printer-friendly,  so 
users  have  the  option  to  view  them  online  or  print  them  at  their  convenience.  The 
MAPSS  reports  provide  clear  and  relevant  information  and,  most  importantly,  another 
layer  of  decision-support  for  the  aviation  logistics  community. 
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Figure  27.  Operation  Sustainment  Process 

This  chapter  discussed  the  RAD  methodology  and  the  significance  of  Microsoft 
Access  2003,  Microsoft  Visio  2003,  and  Macromedia  Dreamweaver  MX  2004  as 
development  tools.  This  chapter  also  presented  the  graphical  representations  of  how  data 
is  physically  stored  in  the  relational  database  and  how  data  is  manipulated  and  processed 
to  accomplish  system  requirements  for  the  aviation  logistics  warfighter.  Although 
models  represent  a  view  of  reality,  it  is  the  implementation  and  deployment  of  a  system 
that  determines  the  level  of  reality  that  has  been  met,  which  is  the  topic  of  Chapter  V. 
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V. 


PROTOTYPE  IMPLEMENTATION  AND  DEPLOYMENT 


This  chapter  discusses  interface  and  web  design  features  that  were  considered 
during  the  implementation  of  the  MAPSS  prototype.  Deployment  feedback  received  by 
the  aviation  logistics  professionals  that  agreed  to  participate  in  this  researched  is  also 
discussed. 

This  chapter  is  organized  as  follows.  Section  A  describes  the  importance  of 
typography,  color  scheme,  cascading  styles  sheets,  templates,  navigation  and  information 
structure  in  web  design;  and  Section  B  discusses  the  benefits  of  end-user  interaction 
within  the  prototyping  process,  and  then  describes  the  positive  feedback  and  constructive 
criticism  received  for  the  first  iteration  of  the  prototype. 

A.  INTERFACE  DESIGN  CONSIDERATIONS 

Designing  the  user  interface  is  vital  to  the  success  of  any  web-centric  application; 
it  is  the  difference  between  a  system  that  gets  used  regularly,  reluctantly,  or  not  at  all.  In 
addition  to  the  user’s  functional  needs  and  system  requirements,  there  are  some 
universally  accepted  concepts  of  web  design  that  should  be  considered:  (1)  clear  and 
readable  typography,  (2)  consistent  color  scheme,  (3)  effective  navigational  structure,  and 
(4)  logically  organized  information. 

1.  Typography  and  Color  Scheme 

In  broad  terms,  typography  refers  to  the  use  of  typeface  and  font,  the  former  is  the 
style  of  text  (i.e.  Times  New  Roman,  Arial  and  Verdana)  and  latter  is  the  physical  size  of 
the  typeface  (i.e.  10,  12  and  14  point  font).  Typeface  and  font  sizes  should  be  considered 
and  selected  early  and  maintained  throughout  the  development  process,  using  too  many 
techniques  at  one  time  only  leads  to  screen  clutter  and  the  impression  of  confusion  [16]. 
Both  typeface  and  font  size,  if  used  consistently,  provide  an  effective  and  legible  web 
interface  for  users. 

Color  scheme  is  another  important  consideration.  When  used  properly,  color  can 
enhance  the  presentation  of  your  infonnation,  providing  structural  and  navigational  clues 
for  the  user.  Conversely,  poor  use  of  color  distracts  from  content  and  can  annoy  users 
[18].  Color  schemes  and  the  subsequent  effect  on  the  user’s  cognitive  processes  is  a 
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highly  specialized  and  technical  field,  which  is  beyond  the  scope  of  this  thesis.  A  good 
rule  of  thumb,  however,  is  to  select  contrasting  colors  for  text  and  backgrounds.  To 
maximize  legibility,  light  colored  text  against  dark  backgrounds  or  dark  colored  text 
against  light  colored  backgrounds  should  normally  be  used. 

Both  typography  and  color  scheme  were  a  deliberate  design  consideration  in  the 
development  of  the  MAPSS  prototype.  Verdana  was  selected  as  the  typeface.  It  is  an 
appropriate  typeface  for  web  applications  because  it  is  an  expanded  typeface,  meaning 
that  each  letter  takes  up  more  horizontal  space  on  the  page  making  it  much  easier  to  read 
(and  thus  comprehend)  compared  to  other  typefaces.  The  tradeoff,  however,  is  that  it 
may  increase  the  vertical  length  of  web  pages  and  lead  to  the  use  of  the  scroll  bar  to  see 
all  of  the  presented  information.  For  the  MAPSS  prototype,  the  positives  outweighed  the 
negatives;  dark  colored  (#990000)  Verdana  typeface  against  a  light  colored  background 
(#FFFFCC)  was  chosen.  The  following  figure  illustrates  the  typography  and  color 
scheme  for  MAPSS  prototype. 


Figure  28.  Typography  and  Color  Scheme 

Font  sizes  were  also  considered  in  the  development  of  the  prototype  with  the 
purpose  of  maintaining  consistency.  Font  sizes  are  important  not  only  for  legibility 
purposes,  but  also  because  they  provide  hierarchical  structure  and  act  as  navigational 
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clues  for  users  to  effectively  traverse  the  system.  Font  sizes  can  be  used  to  separate 
major  sections  of  text  such  as  headings  and  sub-headings  or  be  used  to  display  system 
functionality  such  as  hyperlinks. 

The  basics  of  web  design,  clear  and  readable  typography  and  a  consistent  color 
scheme,  is  easily  implemented  and  maintained  by  recent  improvements  in  web 
development  technology.  Two  examples  are  the  use  of  templates  and  cascading  style 
sheets  (CSS).  Templates  are  used  to  maintain  static  or  unchanging  aspects  of  pages 
within  a  site  (i.e.,  graphics,  images,  and  navigational  links)  while  allowing  developers  to 
add  content  to  “unlocked”  sections  of  pages  [19].  The  end  result  is  a  consistent  intra-site 
web  design  and  not  the  perception  of  multiple  web  pages  linked  together.  Dreamweaver 
MX  2004  provides  excellent  functionality  for  using  templates,  which  includes  creating, 
updating,  and,  if  needed,  quickly  removing  templates  from  web  pages.  The  following 
figure  depicts  the  MAPSS  template  that  was  used  throughout  the  development  process  to 
create  the  consistent  “look  and  feel”  for  the  prototype. 


Figure  29.  Template  Displayed  in  Dreamweaver  MX  2004 


Another  important  web  technology  is  Cascading  Style  Sheets  (CSS).  In  fact, 
“CSS  is  the  preferred  method  of  controlling  the  layout  and  design  features  of  a  modern 
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web  site”  [19].  CSS  is  best  described  as  an  external  set  of  rules  that  can  be  applied  to  as 
many  web  pages  as  needed — literally  thousands.  CSS  are  the  blueprints  of  how 
information  is  displayed  on  a  user’s  screen.  This  is  a  powerful  and  extremely  efficient 
tool  for  web  developers.  For  example,  an  organization  may  want  to  update  or  change  its 
theme  on  all  of  its  web  pages,  maybe  change  from  a  Times  New  Roman  to  an  Arial 
typeface.  Using  CSS,  this  can  be  done  in  a  matter  of  minutes  simply  by  editing  a  single 
style  sheet.  Comparing  this  process  to  those  in  the  past,  where  changes  were  laboriously 
made  to  each  and  every  web  page,  the  benefits  and  efficiency  of  using  CSS  quickly 
become  apparent.  CSS  is  rapidly  revolutionizing  web  design  and  site  maintenance;  it 
allows  organizations  to  efficiently  control  the  style  and  theme  of  their  web  presence  in  a 
dynamic  environment,  which  in  today’s  highly  competitive  atmosphere  can  be  the 
difference  between  prosperity  and  mere  survival.  CSS  was  used  in  the  development  of 
MAPSS.  All  regular  text,  headings,  hyperlinks,  menus,  textboxes,  forms  and  tables  for 
the  prototype  were  developed  and  maintained  using  a  master  style  sheet.  Although  all 
web  developers  can  benefit  from  the  use  of  CSS,  it  is  especially  conducive  for  developing 
prototypes  where  numerous  changes  are  expected  and  expected  often. 

2.  Navigation  and  Information  Structure 

Typography  and  color  scheme  are  only  one  aspect  of  user  interface  design;  a  well- 
organized  navigational  structure  and  logically  organized  information  are  vital  attributes 
for  an  effective  web-centric  application.  In  Principles  of  Web  Design,  Joel  Sklar  outlines 
the  requirements  for  creating  usable  system  navigation:  (1)  users  should  always  know 
where  they  are,  (2)  users  should  always  know  where  they  can  go,  (3)  users  should  always 
know  how  to  get  there,  and  (4)  users  should  always  know  how  to  get  back  to  where  they 
started.  The  author  also  leaves  little  doubt  about  the  importance  of  logically  organizing 
information  on  the  web  page:  “information  design  is  the  single  most  important  factor  in 
determining  the  success  of  your  site”  [18]. 

As  discussed  in  Chapter  IV,  MAPSS  consists  of  three  modules;  therefore,  the 
navigational  structure  of  the  application  is  aligned  with  the  functional  requirements  of 
developing  Concepts  of  Operation  (CONOPS),  Courses  of  Action  (COA),  and  sustaining 
deployed  aviation  logistics  forces.  An  intentional  development  strategy  for  the  prototype 
was  to  incorporate  a  navigational  structure  that  was  consistent  with  the  natural  workflow 
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of  current  planning  and  sustaining  processes  of  the  MALS.  The  following  figures 
illustrate  the  interfaces  of  the  three  modules  of  the  MAPSS  prototype. 


Figure  30.  Concept  of  Operations  Development  Page 
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The  figures  above  reflect  a  coherent  navigational  structure  and  a  logically 
organized  text-based  informational  design.  All  three  modules  are  consistent,  each  having 
a  navigation  side-bar  on  the  left  side  of  the  page  and  relevant  text-based  information 
arranged  in  table  format,  which  is  neatly  framed  within  color-coded  blocks  with 
appropriate  headings  describing  the  enclosed  content.  The  position  of  the  navigation  bar 
on  the  left  side  of  the  page  is  a  proven  web  usability  technique.  In  a  recent  usability 
study  of  both  novice  and  experienced  web  users,  over  60%  of  the  users  expected  internal 
links  to  be  positioned  on  the  left  side  of  the  page  [20].  Hence,  the  design  of  the  MAPSS 
system  takes  advantage  of  a  familiar  web  navigation  convention  for  both  novice  and 
experienced  users. 

The  MAPSS  prototype  also  measures  well  against  Sklar’s  criteria  for  usable 
system  navigation.  First,  users  of  MAPSS  should  not  have  a  problem  identifying  “where 
they  are”  in  the  system.  Every  web  page  has  clear  headings  at  the  top  of  the  page  which 
describes  its  purpose.  Location  paths  are  also  employed  to  assist  users  in  maintaining 
their  orientation  within  the  system.  The  following  figure  depicts  the  concept. 


Figure  33.  Use  of  Location  Paths 
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Location  paths  are  an  effective  design  technique  to  aid  users  with  system 
situational  awareness.  In  the  example  above,  the  user  has  navigated  from  the  Start  page, 
to  the  Operations  List,  Operation  Details,  and  currently  working  with  the  Assign  Aircraft 
to  Operation  page.  The  location  path  in  the  figure  above  also  serves  a  dual  purpose, 
which  conforms  to  Sklar’s  fourth  criteria:  “Users  should  always  know  how  to  get  back  to 
where  they  started.”  Part  of  the  location  path  is  a  hyperlink  back  to  the  Start  page  of  the 
system,  the  launching  point  for  all  modules  of  the  MAPSS  prototype.  In  addition  to 
location  paths,  a  “home”  hyperlink  is  also  provided  on  each  page  under  the  MAPSS 
banner. 

Sklar’s  other  two  measures  of  effectiveness,  users  should  always  know  “where” 
they  can  go  and  “how”  to  get  there,  are  accomplished  as  well.  As  previously  discussed, 
each  system  module  has  a  navigational  side  bar  located  on  the  left  side  of  the  web  page 
that  contains  all  relevant  “where”  infonnation  for  that  module’s  functionality.  The  fact 
that  all  the  “where”  information  is  also  a  hyperlink  inherently  provides  the  “how” 
information  as  well.  Furthennore,  all  of  MAPSS’  functionality  is  accessed  from  just 
three  web  pages,  so  the  user’s  situational  awareness  is  easily  maintained  and  any  “where” 
and  “how”  information  that  users  may  need  is  just  a  mouse-click  away. 

The  last  two  design  considerations  are  related  to  efficient  information  structure. 
As  discussed  in  Chapter  III,  current  aviation  logistics  planning  is  a  manual  and  time 
consuming  process  resulting  from  the  lack  of  systems  integration;  planners  are  required 
to  access  multiple  information  management  systems  to  source  aviation  logistics  support 
plans.  By  far,  the  most  significant  aspect  of  the  MAPSS  prototype  is  the  four-into-one 
system  integration  design;  MAPSS  combines  the  data  sets  from  four  different  systems 
into  one  logically  organized  user  interface.  The  COA  development  page,  depicted  in 
Figure  31  above,  demonstrates  the  systems  integration  concept,  where  information  on  the 
page  represents  integrated  data  for  entities  (from  system):  Personnel  (MCTFS),  Repair 
Parts  (NALCOMIS),  Support  Equipment  (IMRL),  and  Mobile  Facilities  (TBA).  This 
functionality  alone  has  the  potential  to  be  a  mission  multiplier  and  increase  the  efficiency 
of  planning  and  sustaining  deployed  forces. 

The  last  design  consideration  is  the  presentation  of  the  information.  System 
requirements  are  essential  for  any  system  design;  however,  location  of  the  user  and  how 
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he/she  interfaces  with  the  system  is  equally  important.  With  this  in  mind,  MAPSS  was 
designed  as  a  low-bandwidth  system;  the  interface  is  predominately  text-based.  Although 
detailed  graphics,  multimedia  and  other  interactive  features  attract  and  make  web  sites 
more  aesthetically  appealing,  these  features  come  with  a  cost — bandwidth.  Bandwidth  is 
a  precious  commodity  in  the  armed  forces,  especially  for  deployments  in  austere 
locations.  As  result,  the  MAPSS  prototype  was  intentionally  designed  to  maximize  the 
bandwidth-friendly  characteristics  of  text.  The  prototype  was  designed  for  a  baseline 
56K  bps  data  connection,  which  is  a  common  constraint  in  today’s  environment  using 
organic  communications  such  as  the  INMARSAT  system,  aboard  an  LHA/LHD  with  a 
MEU,  or  operating  on  a  T-AVB  ship.  MAPSS,  as  a  text-based  system,  allows  users  to 
quickly  access  and  complete  necessary  transactions  which  lead  to  an  increased  combat 
readiness  of  the  MAGTF  ACE.  Deployed  aviation  logistics  personnel  cannot  be  hindered 
by  time-consuming  downloads  of  images,  graphics  or  multimedia  in  their  march  for 
mission  accomplishment. 

B.  PROTOTYPE  DEPLOYMENT  AND  FEEDBACK 

The  benefit  of  the  RAD  methodology  is  the  iterative  process  of  designing,  testing, 
and  refining  the  potential  system.  User  involvement  is  the  cornerstone  requirement  for 
every  prototype.  Both  developers  and  users  benefit  from  the  interaction.  Developers  can 
identify  and  solve  design  and  functionality  issues  earlier  in  the  system  development 
process,  which  is  conducive  to  delivering  a  system  on  time  and  on  schedule.  Users,  on 
the  other  hand,  can  identify  and  refine  actual  system  requirements  before  the  system  is 
delivered  and  does  not  do  what  was  expected  or  needed.  “The  basic  principle  behind 
prototyping  is  that  users  know  what  they  want  when  they  see  it  working”  [10]. 

1.  Prototype  Deployment 

The  active  end-users  for  the  first  iteration  of  the  prototype  were  Operations 
Officers  from  MALS-1 1  and  MALS-36.  Both  field-grade  officers  agreed  to  participate  in 
this  research  and  provide  the  necessary  feedback  on  the  prototype.  As  mentioned  in 
Chapter  III,  MALS  Operations  (S-3)  Officers  are  the  lead  planners  for  aviation  logistics 
at  the  tactical-level;  hence,  they  are  primary  intended  users  of  the  system. 

The  ideal  situation  for  any  prototype  implementation  is  face-to-face  interaction 

between  the  developer  and  the  user.  Face-to-face  interaction  allows  developers  to  clearly 
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explain  and  demonstrate  the  system  and  provide  any  necessary  training.  For  much  of  the 
same  reasons,  users  benefit  from  face-to-face  interaction  because  it  is  an  opportunity  to 
get  important  questions  answered  quickly  and  clearly  express  any  issues,  problems  or 
suggestions  that  arise  with  the  system.  Overall,  face-to-face  interaction  is  beneficial  to 
all  involved  and  sets  the  tone  for  smooth  transitions  of  future  prototype  iterations. 
Unfortunately,  face-to-face  interaction  was  not  a  possibility  for  the  MAPSS  prototype. 
Funding,  operational  tempo  and  the  geographic  divide  made  face-to-face  interaction  for 
this  iteration  improbable.  Considering  the  prototype  is  a  web-enabled  application, 
however,  the  impact  was  lessened  considerably.  Users  accessed  the  system  via  the 
Internet,  which  was  a  test  of  system  design  and  capability  in  and  of  itself. 

The  MAPSS  prototype  was  hosted  on  a  web  server  in  the  Database  and  Web 
Technologies  Lab  at  the  Naval  Postgraduate  School.  The  web  server  provided  unlimited 
and  uninterrupted  access  during  the  development  and  deployment  of  the  prototype. 
Before  access  (username  and  password)  was  granted  to  users,  a  pre-deployment  brief  was 
provided  to  both  squadrons.  The  intent  of  the  brief  was  to  explain  the  purpose  of  the 
prototype,  discuss  the  design  of  the  system,  and  define  all  system  functionality. 
Conceptual  data  models,  logical  process  models,  and  multiple  screenshots  of  the  system 
were  provided.  Users  were  encouraged  to  get  all  questions  answered  when  arisen,  either 
prior  to  accessing  the  system  or  during  the  evaluation  period. 

The  deployment  of  the  first  version  of  the  MAPSS  prototype  had  the  following 
objectives:  (1)  confirm  initial  systems  requirements,  (2)  collect  any  new  or  refined 
system  requirements,  and  (3)  test  the  usability  features  of  the  prototype.  To  facilitate  the 
evaluation  of  the  prototype,  the  MAPSS  web-enabled  application  contained  several 
fictitious  operations,  all  in  various  stages  of  development.  Some  operations  were  fully 
developed,  meaning  all  modules  (CONOPS,  COA  and  Dashboard)  contained  data  while 
other  operations  were  in  the  initial  or  definition  stage  of  development.  Users  were 
instructed  to  browse  and  test  all  functionality  of  the  system.  They  were  given  the 
freedom  to  add,  update,  delete,  assign,  and  remove  data  as  they  saw  fit.  Users  were  given 
a  two-week  period  to  evaluate  the  first  version  and  provide  the  necessary  feedback  on  the 


59 


system.  Although  face-to-face  interaction  did  not  occur,  the  evaluation  period  was 
considered  a  success:  concise,  insightful,  and  constructive  feedback  was  attained  that  can 
be  used  to  further  improve  the  system. 

2.  Prototype  Feedback 

a.  Positive  Feedback 

Overall,  the  feedback  received  for  a  first  version  of  the  prototype  was 
positive,  which  was  very  encouraging.  The  overarching  design  concept  of  using  three 
different  modules  (CONOPS  Development,  COA  Development,  and  Operation 
Dashboard)  was  favorably  received.  The  following  are  some  positive  comments  received 
about  the  MAPSS  prototype: 

(1)  The  ability  to  compare  COA  by  weight,  square-feet,  and 
cubic  feet  is  good  feature  because  limited  availability  for  lift  is  always  an  issue  for 
getting  AVLOG  in  theater. 

(2)  The  Operation  Dashboard  is  a  nice  function  for 
distinguishing  problems  or  areas  of  concern  for  personnel,  parts,  support  equipment, 
mobile  facilities,  and  aircraft.  It  is  a  needed  element,  especially  for  other  horizontal  and 
vertical  commands  to  quickly  grasp  current  status. 


(3) 

The  ability  to  perform  material  requisition  management  is  a 

nice  feature. 

(4) 

The  system  is  easy  to  navigate. 

(5) 

The  font  and  color  scheme  combine  to  make  the  system 

easy  to  read. 

(6) 

Information  was  very  logically  organized. 

(7) 

The  low-bandwidth  design  is  a  must  for  operational  forces. 

The  interface  should  be  as  simple  as  possible  due  to  the  possibility  of  having  extremely 
low-bandwidth  at  deployed  sites. 


b.  Constructive  Criticism 

Like  most  first  version  prototypes,  there  was  no  shortage  of  constructive 
criticism.  Successfully  implementing  all  system  requirements  and  having  a  completely 
functional  system  is  highly  unlikely  and  simply  unrealistic  with  the  first  iteration  of  any 
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prototype.  Constructive  feedback  is  essential;  it  is  one  of  the  primary  benefits  that 
prototyping  has  over  other  system  development  methodologies.  Feedback  should  be 
collected,  considered,  and  used  to  further  improve  the  system.  The  following  is  the 
constructive  criticism  received  on  the  MAPSS  prototype: 

(1)  Assigning  the  same  personnel,  parts,  support  equipment, 
and  mobile  facilities  to  multiple  COA  options  is  a  tedious  process.  The  system  needs  the 
capability  to  assign  individual  support  components  to  multiple  COA  options  with  one 
transaction. 

(2)  The  system  should  automatically  generate  a  generic  COA 
shell  based  upon  initial  CONOPS  development.  The  system  needs  the  capability  to 
import  logistics  pack-ups  or  groups  of  personnel,  parts,  support  equipment,  and  mobile 
facilities. 

(3)  Course  of  action  comparison  would  be  more  efficient  if 
displayed  side-by-side  on  a  single  web  page  instead  of  toggling  back  and  forth. 

(4)  Mouse-over  messages  are  needed  for  red  and  yellow  lights 
on  the  Operation  Dashboard,  which  would  explain  why  mission-capability  is  low. 

(5)  Suggest  a  different  but  consistent  color  scheme  for  each 
logistics  support  component.  For  example,  the  color  blue  for  parts,  gray  for  support 
equipment,  and  orange  for  personnel  information.  Color-coding  would  allow  users  to 
quickly  identify  a  particular  section  of  interest. 

(6)  The  CONOPS  Development  module  needs  the  functionality 
to  add  more  narrative  for  an  operation,  such  as  commander’s  intent,  type  of  mission,  and 
operational  assumptions. 

(7)  The  UDL/TPFDD  summary  needs  some  refinement  to 
make  it  MDSS-II  compatible. 

The  evaluation  of  the  first  iteration  of  the  MAPSS  prototype  was 
beneficial.  It  revealed  that  the  web-centric  application  is  a  viable  product  that  should  be 
further  developed  to  meet  the  needs  of  the  aviation  logistics  warfighter.  It  was  an 
opportunity  to  assess  what  the  system  did  well  and  what  areas  need  improvement.  The 
evaluations  by  both  Operations  Officers  were  instrumental  in  paving  the  future  direction 
of  the  system.  The  road  ahead  involves  more  analysis,  more  development,  more 
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refinement,  and  more  testing.  This  version  is  just  the  first  of  many  prototypes  that  will 
ultimately  lead  to  a  system  that  satisfies  tactical-level  aviation  logistics  planning  and 
sustainment  requirements.  Prototype  development  must  continue  in  parallel  with  the 
current  aviation  logistics  transfonnation  of  the  Marine  Corps.  In  short,  the  road  ahead  is 
long  but  necessary. 

This  chapter  discussed  the  user  interface  and  web  design  features 
that  were  considered  during  the  implementation  of  the  MAPSS  prototype  as  well  as  the 
deployment  feedback  received  by  the  aviation  logistics  professionals  of  MALS-11  and 
MALS-36.  The  deployment  and  subsequent  feedback  on  the  first  prototype  iteration  was 
an  essential  step  in  the  application’s  development  cycle.  Another  key  research  activity 
accomplished  for  thesis  was  a  usability  study,  which  is  the  subject  of  Chapter  VI. 
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VI.  USABILITY  TESTING 


This  chapter  describes  the  methodology,  experimental  design,  and  test  metrics  of 
the  usability  study  that  was  accomplished  on  the  MAPSS  prototype.  The  results  of  the 
usability  study  and  its  contribution  towards  improving  system  effectiveness,  efficiency, 
and  user  satisfaction  are  also  discussed. 

This  chapter  is  organized  as  follows.  Section  A  describes  the  “who,  what,  when, 
where,  and  why”  of  the  usability  study;  Section  B  describes  the  interaction  between  test 
equipment,  participants  and  administrators;  Section  C  describes  the  test  metrics  that  were 
captured  during  the  study;  and  Section  D  is  the  analysis  of  system  effectiveness, 
efficiency,  and  user  satisfaction. 

A.  METHODOLOGY 

The  primary  objective  of  the  usability  study  was  to  evaluate  the  effectiveness, 
efficiency,  and  satisfaction  with  which  specified  users  can  achieve  specified  goals  in  a 
particular  environment  [21].  The  usability  test  was  focused  on  user  interaction  as  it 
relates  to  system  functionality,  navigation,  design,  and  information  architecture,  which 
could  then  be  used  as  a  baseline  for  future  prototype  iterations. 

The  usability  test  was  conducted  at  the  Database  and  Web  Technologies  Lab, 
Naval  Postgraduate  School,  Monterey,  California,  on  May  17,  2006,  between  the  hours  of 
0800-1300.  The  study  was  facilitated  by  a  test  administrator  and  two  observers,  whose 
primary  responsibilities  were  to  collect  test  metrics  of  the  study.  Five  participants  were 
selected  on  a  voluntary  basis  to  participate  in  the  study.  Three  participants  (60%)  were 
Marine  Corps  Officers  with  primary  military  occupational  specialties  (MOS)  in  Marine 
Corps  Aviation;  two  of  which  were  Aviation  Logistics  Officers,  intended  users  of  any 
future  fielded  system  for  aviation  logistics  planning  and  sustainment.  One  participant 
was  a  Marine  Corps  Communications  Officer  with  extensive  deployment  experience  and 
intimately  familiar  with  the  Marine  Corps  Planning  Process  (MCPP).  The  fifth 
participant  was  an  international  officer  from  the  Hellenic  Navy.  The  value  of  including 
an  international  officer  in  the  study,  where  the  English  language  was  not  his/her  native 
language,  was  to  capture  the  overall  intuitiveness  and  ease  of  use  of  the  prototype. 
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The  usability  study  was  approved  by  the  NPS  Institutional  Review  Board,  an 
entity  that  maintains  oversight  when  human  subjects  are  involved  in  any  research  at  the 
Naval  Postgraduate  School.  Test  equipment  for  the  usability  test  consisted  of  the 
following: 

•  The  MAPSS  prototype  application  and  supporting  Database  running  under 
Microsoft  Access  2003. 

•  Client  Computer:  Pentium  III/600  MHz  processor,  512  Mb  RAM, 
Microsoft  Windows  NT  2000  Professional  operating  system,  15”  LCD  monitor  with 
resolution  settings  of  1024  x  768  pixels. 

•  Host  Computer:  Dual  Pentium  IV/2.8  GHz  processor,  2  Gb  RAM, 
Microsoft  Server  2003  Enterprise  Edition  operating  system. 

•  Web-browser(s)  on  Client:  Microsoft  Internet  Explorer  v6,  Mozilla 
Firefox  vl.5. 

•  Network:  100  Mbs  Ethernet;  Client  IP  address:  131.120.178.78;  Host  IP 
address:  131.120.251.70;  Domain:  ebiz.nps.navy.mil. 

•  Two  Digital  video  cameras  with  tripod. 

B.  EXPERIMENTAL  DESIGN 

The  client  workstation  was  setup  with  one  digital  video  camera  recording  the  on¬ 
screen  transactions  of  the  participant,  and  a  second  digital  video  camera  was  setup  to 
record  the  facial  expressions  of  the  user.  Both  digital  video  cameras  were  equipped  with 
microphones;  audio  was  recorded  to  capture  user  comments.  All  participants  signed  a 
consent  form  and  privacy  act  statement,  authorizing  audio/video  recording  for 
educational  purposes  and  to  ensure  the  identity  of  each  participant  was  protected  against 
unauthorized  disclosure. 
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Figure  34.  Usability  Test  Experimental  Design 

The  experiment  consisted  of  three  phases:  Concept  of  Operation  Development, 
Course  of  Action  Development,  and  Operation  Sustainment.  All  participants  were  given 
scenario-based  tasks  to  complete  for  each  phase  of  the  experiment.  Participants  were  also 
encouraged  to  “think  aloud,”  verbalizing  their  actions,  thoughts,  and  any  aspects  of  the 
task  that  may  have  been  troubling  to  complete.  Prior  to  starting  the  first  phase  of  the 
experiment,  participants  were  given  five  minutes  to  familiarize  themselves  with  system 
functionality  and  navigation. 

The  administrator  was  on  hand  to  facilitate  the  overall  experiment  and  to  provide 
user  assistance  with  the  system,  if  necessary.  Participants  were  instructed  to  make  three 
attempts  at  completing  a  task  before  requesting  assistance  from  the  administrator. 
Observers  were  also  on  hand  to  record  the  metrics  for  the  experiment.  After 
attempting/completing  all  scenario-based  tasks,  participants  completed  a  post-experiment 
user  survey. 

C.  TEST  METRICS 

The  following  test  metrics  were  captured  during  the  study  as  a  means  to  analyze 
the  usability  and  functionality  features  of  the  prototype. 

1.  System  Effectiveness 

a)  Did  the  participant  complete  the  task  successfully?  (Yes/No) 

b)  Did  the  participant  require  assistance  from  the  administrator  to 
complete  the  task?  (Yes/No) 
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c)  What  type  of  assistance  was  provided?  (e.g.  definition  of  a  term  or 
acronym,  clarification  of  a  requirement  related  to  the  scenario-based  task,  and/or 
correctly  navigating  to  complete  the  scenario-based  task) 

d)  Number  of  occurrences  for  assistance  required  for  completing  a 

task. 

e)  Number  of  application  or  system  errors  (e.g.  incorrect  data 
displayed  or  a  page  failed  to  load). 

2.  System  Efficiency 

a)  Time  (seconds)  to  complete  an  individual  scenario-based  task. 

b)  Number  of  mouse-clicks  to  complete  an  individual  scenario-based 
task.  (e.g.  clicks  on  hyperlinks,  web  page  or  browser  buttons  or  icons)  Note:  a  double¬ 
click  to  initiate  an  action  was  equivalent  to  one  click. 

3.  System  Satisfaction 

a)  All  participants  completed  a  post-experiment  survey. 

D.  USABILITY  TEST  RESULTS 

1.  System  Effectiveness 

The  usability  test  was  designed  to  examine  the  major  functionality  components  of 
the  system:  CONOPS  Development,  COA  Development  and  Operation  Sustainment. 
User  participation  for  the  study  was  designed  for  one-hour  duration.  Each  participant 
was  asked  to  complete  19  scenario-based  tasks  encompassing  the  most  significant  system 
requirements.  As  a  result,  with  five  participants  in  the  study,  there  were  a  total  of  95  (19 
x  5)  possible  tasks  to  be  assessed. 

The  results  of  the  first  metric  for  system  effectiveness  were  very  encouraging.  All 
participants  of  the  study  were  able  to  successfully  complete  all  19  scenario-based  tasks. 
Although  100%  of  the  tasks  were  completed  successfully,  assistance  from  the 
administrator  was  required  for  20%  of  the  tasks  attempted;  there  were  a  total  of  19 
scenario-based  tasks,  an  average  of  one  task  per  participant  where  assistance  from  the 
administrator  was  required.  Hence,  80%  of  all  scenario-based  tasks  were  completed 
without  assistance.  The  majority  of  assistance  occurred  during  the  first  phase  of  the 
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experiment:  CONOPS  Development.  Assistance  required  at  the  beginning  of  the 
experiment  was  mainly  attributed  to  the  general  unfamiliarity  participants  had  with  the 
system  and  its  navigation  architecture.  All  participants  had  never  seen  or  used  MAPSS 
previously  and  only  received  five  minutes  to  familiarize  themselves  with  the  system  prior 
to  the  experiment.  As  the  experiment  progressed,  however,  less  assistance  was  required 
due  to  the  participant’s  increased  knowledge  of  the  system  and  its  functionality. 

The  next  system  effectiveness  metric  that  was  captured  during  the  study  was 
system  errors.  The  intent  was  to  capture  any  system  bugs  or  errors  in  the  web-enabled 
database  which  would  prevent  participants  from  successfully  completing  a  task.  Ninety- 
four  (94)  of  95  scenario-based  tasks  were  completed  without  a  system  error.  The  single 
(1)  system  error  occurred  during  the  CO  A  Development  phase  of  the  experiment,  where  a 
participant  attempted  to  assign  a  part  to  a  COA.  The  correct  procedure  for  the  task  called 
for  assigning  a  particular  part  to  a  COA  with  both  “on-hand”  and  “allowance”  quantities 
having  a  numeric  value,  since  both  “on-hand”  and  “allowance”  quantities  are  required 
fields  in  the  database  schema.  However,  the  participant  submitted  the  “assign  to  COA” 
form  without  inputting  a  value  for  the  “allowance”  quantity  which  resulted  in  the  system 
error. 

The  system  error  was  result  of  the  “assign  part  to  COA  page”  not  having  the 
proper  fonn  validation  procedures  implemented,  an  oversight  in  the  development  of  the 
web  page.  To  prevent  system  errors  of  this  nature,  the  active  server  page  should  first 
validate  that  all  required  fields  on  the  form  have  acceptable  values,  and  only  then  submit 
the  data  to  append  the  database.  This  error  was  quickly  corrected  by  implementing  the 
proper  form  validation  code  to  the  active  server  page,  ensuring  that  both  “on-hand”  and 
“allowance”  values  had  acceptable  numeric  values  before  submitting  the  data  to  append 
the  database.  Nonetheless,  the  study  was  completed  with  just  a  1%  error  rate,  very 
acceptable  for  a  first-version  prototype. 

2.  System  Efficiency 

The  purpose  of  capturing  the  time  and  number  of  mouse-clicks  (amount  of  effort) 
it  took  for  participants  to  complete  the  scenario-based  tasks  was  to  identify  trends  and 
potential  navigation  problems  with  the  usability  of  the  system.  In  the  analysis  of  the  data, 
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three  navigation  issues  were  identified  by  the  high  standard  deviation  of  time  and  number 
of  mouse-clicks  it  took  the  participants  to  complete  the  scenario-based  task.  Table  2 
illustrates  the  three  potential  issues  identified  during  the  usability  test. 


Phase 

Task 

Time  (seconds) 

Mouse-clicks 

CONOPS  Development 

Assign  Squadron  to  Operation 

81.8 

6.9 

CONOPS  Development 

Assign  Aircraft  to  Operation 

102.3 

4.5 

COA  Development 

Assign  Personnel  to  COA 

75.5 

14.6 

Table  2.  Potential  Issues  Identified  During  The  Usability  Experiment 

The  first  two  issues  occurred  during  phase  one  (CONOPS  Development)  of  the 
experiment.  Aside  from  initially  logging  into  the  system  to  start  the  experiment, 
assigning  squadrons  and  aircraft  to  the  operation  were  the  first  two  scenario-based  tasks 
to  be  attempted/completed.  The  third  issue,  assigning  personnel  to  a  COA,  was  the  first 
scenario-based  task  in  phase  two  (COA  Development)  of  the  experiment. 

Two  factors  may  explain  these  potential  issues.  First,  as  previously  discussed, 
each  participant  was  given  just  five  minutes  to  familiarize  themselves  with  the  system; 
hence,  initial  tentativeness,  apprehensiveness  and  caution  were  expected  and  experienced 
in  each  phase  of  the  usability  test.  As  the  study  progressed  and  participants  became  more 
comfortable  with  the  navigation  of  the  system,  the  standard  deviation  of  time  and  mouse- 
clicks  to  complete  each  task  decreased  significantly.  For  example,  scenario-based  tasks 
in  phase  two  required  participants  to  assign  personnel,  repair  parts,  support  equipment, 
and  mobile  facilities  to  a  COA.  The  standard  deviation  for  assigning  personnel  alone  was 
75.5  seconds  and  14.6  mouse-clicks,  but  the  average  standard  deviation  for  assigning  the 
remaining  repair  parts,  support  equipment,  and  mobile  facilities  decreased  to  22.2 
seconds  and  5.4  mouse-clicks,  a  decrease  in  time  and  amount  of  effort  of  71%  and  63% 
respectively.  This  decrease  is  a  clear  indication  that  participants  of  the  usability  study 
were  learning  the  navigation  architecture  of  the  system  and  beginning  to  use  it 
effectively. 
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System  navigation  architecture  is  another  factor  that  may  explain  the  potential 
issues  identified  in  Table  2.  As  mentioned  in  Chapter  V,  each  module  of  the  system  is 
designed  with  a  navigation  side-bar  on  the  left  side  of  the  web  page  that  includes 
hyperlinks  to  all  relevant  functionality  for  that  module. 


Figure  35.  CONOPS  Development  usability  issue 
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Figure  36.  CO  A  Development  usability  issue 


As  depicted  in  Figures  35  and  36,  multiple  hyperlinks  are  provided  for  each 
component  of  the  module.  Although  all  modules  are  consistently  designed,  participants 
of  the  usability  study  experienced  problems  differentiating  between  the  “add”  and 
“assign”  functionality  of  the  system;  therefore,  a  few  participants  of  study  spent  a 
considerable  amount  of  time  and  mouse-clicks  incorrectly  “adding”  personnel  to  the 
system  instead  of  correctly  “assigning”  personnel  to  the  CO  A. 

Future  iterations  of  the  prototype  may  benefit  from  a  re-design  of  the  navigation 
architecture.  One  potential  solution  is  to  develop  a  fourth  module,  a  “System 
Administration”  module  where  basic  database  management  functionality  (for  all 
interoperable  systems)  is  included  on  one  web  page.  This  redesign  would  eliminate  all 
system  management  functionality  from  the  three  primary  modules,  which  could 
potentially  reduce  any  visual  and/or  logical  ambiguity  for  users.  The  trade-off,  of  course, 
is  a  fourth  module  to  design,  create,  update  and  maintain.  This  redesign,  however,  would 
have  minimal  impact  on  the  current  data  and  logical  process  models  of  the  system.  Most 
importantly,  the  redesign  would  be  largely  transparent  to  the  intended  users  of  the 
system. 
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3.  System  Satisfaction 

All  participants  of  the  usability  study  completed  a  post-experiment  survey.  The 
survey  was  designed  to  capture  the  participant’s  degree  of  satisfaction  with  the 
prototype’s  functionality  and  usability  features.  The  survey  consisted  of  23  questions:  15 
pertaining  to  system  functionality  and  nine  questions  relating  to  the  general  usability 
features  of  the  system.  Participants  were  asked  to  indicate  their  level  of  satisfaction  using 
a  four-point  rating  scale. 


Scale 

Rating 

1 

Extremely  Dissatisfied 

2 

Dissatisfied 

3 

Satisfied 

4 

Extremely  Satisfied 

Table  3.  Post-Experiment  Survey  Metrics 

Although  data  from  such  a  small  pool  of  participants  did  not  provide  the  basis  for 
any  significant  statistical  analysis,  it  did  provide  valuable  and  insightful  information  that 
can  be  used  for  implementing  future  enhancements  to  the  prototype.  The  results  from  the 
post-experiment  survey  were  overwhelmingly  positive:  the  average  score  for  system 
functionality  was  3.59  and  system  usability  received  a  score  of  3.40.  Both  scores  indicate 
that  users  were  “satisfied”  with  the  first  version  of  the  prototype.  The  following 
illustrations  indicate  the  level  of  satisfaction  from  each  functionality/usability  aspect  that 
was  assessed  during  the  study;  all  respondents  completed  the  survey  immediately 
following  the  usability  experiment. 
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Extremely  Dissatisfied  Dissatisfied  Satisfied  Extremely  Satisfied 


Figure  37.  Survey  Results:  Initiating  CONOPS 


Extremely  Dissatisfied  Dissatisfied  Satisfied  Extremely  Satisfied 

Figure  38.  Survey  Results:  Assigning  Squadrons  to  Operation 


Extremely  Dissatisfied  Dissatisfied  Satisfied  Extremely  Satisfied 


Figure  39.  Survey  Results:  Assigning  Aircraft  to  Operation 
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Extremely  Dissatisfied  Dissatisfied  Satisfied  Extremely  Satisfied 


Figure  40.  Survey  Results:  Establishing  Multiple  COA  for  Operation 


Extremely  Dissatisfied  Dissatisfied  Satisfied  Extremely  Satisfied 


Figure  4 1 .  Survey  Results:  Assigning  Personnel  to  COA 


Extremely  Dissatisfied  Dissatisfied  Satisfied  Extremely  Satisfied 


Figure  42.  Survey  Results:  Assigning  Parts  to  COA 
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Extremely  Dissatisfied  Dissatisfied  Satisfied  Extremely  Satisfied 


Figure  43.  Survey  Results:  Assigning  Support  Equipment  to  COA 


Extremely  Dissatisfied  Dissatisfied  Satisfied  Extremely  Satisfied 


Figure  44.  Survey  Results:  Assigning  Mobile  Facilities  to  COA 


Extremely  Dissatisfied  Dissatisfied  Satisfied  Extremely  Satisfied 


Figure  45.  Survey  Results:  Ability  to  Compare  Multiple  COA 
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Extremely  Dissatisfied  Dissatisfied  Satisfied  Extremely  Satisfied 


Figure  46.  Survey  Results:  Ability  to  Distinguish  Problems 


Extremely  Dissatisfied  Dissatisfied  Satisfied  Extremely  Satisfied 


Figure  47.  Survey  Results:  Ability  to  Determine  Causes  of  Problems 


Extremely  Dissatisfied  Dissatisfied  Satisfied  Extremely  Satisfied 


Figure  48.  Survey  Results:  Ability  to  Identify  Mission  Capability  Percentages 
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Extremely  Dissatisfied  Dissatisfied  Satisfied  Extremely  Satisfied 


Figure  49.  Survey  Results:  Ability  to  Modify  Material  Requisitions 


Extremely  Dissatisfied  Dissatisfied  Satisfied  Extremely  Satisfied 


Figure  50.  Survey  Results:  Ease  of  System  Navigation 


Extremely  Dissatisfied  Dissatisfied  Satisfied  Extremely  Satisfied 


Figure  5 1 .  Survey  Results:  System  Feedback  Methods 
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Extremely  Dissatisfied  Dissatisfied  Satisfied  Extremely  Satisfied 


Figure  52.  Survey  Results:  System  Typography 


Extremely  Dissatisfied  Dissatisfied  Satisfied  Extremely  Satisfied 


Figure  53.  Survey  Results:  System  Color  Scheme 


Extremely  Dissatisfied  Dissatisfied  Satisfied  Extremely  Satisfied 


Figure  54.  Survey  Results:  System  Structure  and  Theme 
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Extremely  Dissatisfied  Dissatisfied  Satisfied  Extremely  Satisfied 


Figure  55.  Survey  Results:  Consistent  System  Design 


Extremely  Dissatisfied  Dissatisfied  Satisfied  Extremely  Satisfied 


Figure  56.  Survey  Results:  Organization  of  Information  Presented 


Extremely  Dissatisfied  Dissatisfied  Satisfied  Extremely  Satisfied 


Figure  57.  Survey  Results:  Ability  to  Drill-Down  for  Additional  Information 
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Extremely  Dissatisfied  Dissatisfied  Satisfied  Extremely  Satisfied 

Figure  58.  Survey  Results:  Low-Bandwidth  Design 

All  participants  of  the  usability  experiment  were  either  “satisfied”  or  “extremely 
satisfied”  with  the  basic  functionality  processes  of  prototype.  However,  four  usability 
aspects  received  at  least  one  “dissatisfied”  response.  The  four  potential  usability 
problem-areas  discovered  were:  (1)  color  scheme,  (2)  typography,  (3)  organization  of 
information  and  (4)  system  feedback  methods.  Video  and  audio  recordings  of  the 
experiment  coupled  with  open-ended  feedback  on  the  post-experiment  survey  were 
essential  in  not  only  identifying  potential  usability  problems,  but  also  providing  potential 
usability  solutions. 

The  prototype’s  problem  with  color  scheme  and  typography  referred  to  the 
navigation  side-bar  on  the  three  modules  of  the  system:  CONOPS  Development,  COA 
Development,  and  Operation  Sustainment.  Feedback  from  participants  revealed  that 
color  scheme  and  font  size  (typography)  for  the  navigation  side-bar  made  hyperlinks 
particularly  hard  to  read.  In  the  past,  correcting  color  schemes  and  typography  involved  a 
significant  amount  of  effort  on  the  developer’s  part — tediously  changing  hundreds  of 
html  tags  to  reflect  the  new  color  and/or  font  style.  Today,  however,  cascading  style 
sheets  (CSS)  allow  many  aspects  of  the  system  to  be  changed  instantly  with  minimal 
effort  [19].  Color  scheme  and  typography  are  important  aspects  of  any  system  design, 
but  since  they  are  easily  manipulated  using  the  latest  web  technology,  these  potential 
problem-areas  are  considered  minor  issues.  Moreover,  the  MAPSS  prototype  was 
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developed  using  CSS;  therefore,  the  developer  of  future  iterations  of  the  prototype  can 
quickly  manipulate  the  color  scheme  and  typography  to  satisfy  intended  users  of  the 
system. 

The  other  two  areas  of  the  prototype  that  received  negative  feedback  were 
“organization  of  information”  and  “system  feedback  methods.”  The  feedback  on  the 
organization  of  information  was  particularly  disconcerting  since  any  effective  decision 
support  system  is  largely  dependent  upon  logically  arranged  information.  Organization 
of  information  should  be  a  primary  system  design  consideration;  it  could  be  the 
difference  between  a  system  that  gets  used  regularly  and  a  system  that  gets  abandoned  by 
intended  users. 

The  usability  experiment  also  uncovered  a  design  flaw  with  the  MAPSS 
prototype:  user  interaction  and  the  level  of  effort  to  accomplish  a  task  were  dependent 
upon  monitor  resolution.  The  following  figures  illustrate  the  problem: 


'3  MAPSS:  Personnel  Add  -  Microsoft  Internet  Explorer 


Figure  59.  Information  Display  on  1024  x  768  Resolution  Monitor 
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Figure  60.  Information  Display  on  1280  x  768  Resolution  Monitor 


In  Figures  59  and  60,  the  difference  in  user  interaction  and  level  of  effort  was 
significant  for  usability  participants  using  a  monitor  with  resolution  setting  of  1024  x  768 
versus  a  monitor  with  a  1280  x  768  resolution.  Users  with  the  lower  resolution  monitor 
are  required  to  use  the  scroll  bar  to  input  data  in  all  required  data  fields  and  submit  the 
form.  On  the  other  hand,  users  with  the  higher  resolution  monitor  have  full  access  to  all 
data  fields  and  the  ability  to  submit  the  fonn  upon  initial  load  of  the  web  page.  The  core 
functionality  remains  unchanged,  but  users  with  a  high  resolution  monitor  use 
significantly  less  effort  to  perform  the  same  operation  in  the  system.  Although  this  issue 
may  seem  like  a  minor  inconvenience  to  users  with  a  low  resolution  monitor,  the  problem 
is  compounded  by  the  repetition  of  the  task  (e.g.  a  user  is  required  to  add  50  or  100 
personnel  to  the  system). 

Good  system  design  dictates  that  user  interfaces  should  be  designed  to  fit  the  most 
common  window  or  monitor  resolutions,  not  just  optimized  for  a  specific  sized  monitor 
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or  resolution  setting  [16].  MAPSS  was  designed,  developed  and  optimized  for  1280  x 
768  resolution;  it  was  not  until  the  usability  experiment  that  the  prototype  was 
extensively  used  and  tested  with  a  1024  x  768  resolution  monitors.  As  a  result,  future 
iterations  of  the  prototype  will  require  some  redesign  so  effective  usability  is  not 
resolution  dependent.  Fortunately,  not  all  web  pages  for  the  system  need  to  be 
redesigned.  Changes  are  limited  to  pages  that  currently  require  a  lot  of  vertical  space  to 
display  all  the  data  fields.  The  following  system  functionality  is  affected  and  should  be  a 
priority  for  future  prototype  iterations. 

1 .  Add  Squadron  to  the  System 

2.  Update  Squadron  to  the  System 

3.  Add  Personnel  to  the  System 

4.  Update  Personnel  to  the  System 

5.  Add  Parts  to  the  System 

6.  Update  Parts  to  the  System 

7.  Assign  Transportation  to  CO  A 

8.  Assign  Host  Nation  Support  to  COA 

9.  Assign  Task  to  COA 

Although  multiple  pages  are  affected,  data  and  logical  process  models  remain 
unchanged  for  the  system.  Redesign  would  be  focused  on  changing  the  structure  of 
presented  information  to  a  more  horizontal  orientation.  Figures  59  and  60,  display  a 
significant  amount  of  “white-space”  available  for  the  redesign.  This  redesign  would 
definitely  benefit  users  with  lower  resolution  settings. 

The  last  aspect  of  the  prototype  to  receive  constructive  criticism  was  “system 
feedback  methods.”  MAPSS  is  web-based  transaction-oriented  application;  therefore, 
system  feedback  is  an  essential  element  of  the  system  and  was  implemented  into  every 
module  of  the  system.  Users  are  notified  via  system  feedback  messages  anytime  data  is 
successfully  added,  updated,  or  deleted  from  any  web  page  within  the  system.  The 
following  figure  is  an  example  of  MAPSS  system  feedback. 
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Figure  6 1 .  System  Feedback  Methods 

The  critique  received  during  the  usability  experiment  was  more  a  result  of 
MAPSS  being  a  text-based  and  first-version  prototype.  Two  participants  of  the  study 
noted  that  system  feedback  methods  were  effective,  but  wanted  to  see  buttons  instead  of 
hyperlinks,  and  wanted  keyboard  shortcuts  to  select  the  “YES”  or  “NO”  options. 
Keyboard  shortcuts  are  an  effective  means  for  experienced  users  to  perform  routine 
actions,  and  both  buttons  and  keyboard  shortcuts  should  be  included  in  any  fielded 
aviation  logistics  planning  system  in  the  future.  However,  for  a  first-version  prototype, 
keyboard  shortcuts  (at  least  in  this  author’s  opinion)  is  an  advanced  feature  better  suited 
for  when  all  system  functionality  is  firmly  cemented  and  aligned  with  customer 
requirements.  System  feedback  methods  will  evolve  as  the  prototype  evolves  into  a  more 
efficient  system. 

The  prototype  also  received  positive  feedback  from  the  usability  experiment. 
Participants  of  the  study  noted  that  the  prototype  was  very  easy  to  use  with  just  a  couple 
of  minutes  of  instruction,  a  good  decision  support  tool  for  the  commander,  an  extremely 
user-friendly  application,  and  a  viable  product  that  the  aviation  logistics  community  can 
expand  upon. 
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This  chapter  described  the  methodology,  experimental  design,  and  test  metrics  of 
the  usability  study  that  was  accomplished  on  the  MAPSS  prototype.  The  results  of  the 
usability  study  and  its  contribution  toward  improving  system  effectiveness,  efficiency, 
and  user  satisfaction  are  also  discussed.  The  development  of  the  MAPSS  prototype  was  a 
challenging  and  rewarding  academic  experience;  a  summary  of  the  experience, 
conclusions  and  directions  for  future  research  are  provided  in  Chapter  VII. 
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VII.  SUMMARY,  CONCLUSIONS,  AND  FUTURE  RESEARCH 


This  chapter  summarizes  the  analysis  of  MALSP  doctrine  and  the  information 
management  systems  used  to  execute  mission  requirements.  Conclusions  are  then  drawn 
on  the  viability  of  the  prototype  to  optimize  multi-level  decision-support  for  deliberate, 
time  sensitive,  and  crisis  action  planning  for  tactical-level  aviation  logistics.  Directions 
and  opportunities  for  future  research  are  also  discussed. 

The  chapter  is  organized  as  follows.  Section  A  summarizes  where  Marine  Corps 
Aviation  Logistics  has  been,  where  it  is  going,  and  why  a  web-enabled  application  is 
needed  to  support  the  transfonnation;  Section  B  discusses  the  conclusions  of  this  thesis 
research  and  frames  the  progress  and  accomplishments;  and  Section  C  provides  direction 
for  future  research  with  the  MAPSS  prototype,  focusing  on  improvements  and 
refinements  that  will  ultimately  to  an  effective  decision  support  system  for  the  21st 
century  logistics  warfighter. 

A.  SUMMARY 

This  thesis  analyzed  the  principles  and  concepts  of  Marine  Aviation  Logistics 
doctrine  at  the  tactical-level  and  the  current  information  management  systems  used  to 
execute  mission  requirements.  The  Marine  Aviation  Logistics  community  is  currently 
undergoing  a  multi-year  doctrinal  transfonnation  from  MALSP  to  MALSP-II.  Although 
current  MALSP  doctrine  has  served  the  community  well  for  over  20  years,  a  new 
strategic  landscape  has  emerged  which  requires  more  flexibility  in  developing  and 
deploying  aviation  logistics  support  forces  and  equipment.  Small-scale  contingencies 
have  become  the  nonn  not  the  exception;  therefore,  the  Marine  Corps  must  refocus  it 
aviation  logistics  support  concepts  from  “standard-sized”  to  “right-sized”  support 
packages. 

Executing  aviation  logistical  operations  will  require  a  robust  decision  support 
system  to  effectively  leverage  the  concepts  of  MALSP-II.  The  current  IT  architecture  for 
planning  and  sustaining  deployed  forces  and  equipment  are  sufficient,  but  not  the  IT 
enabler  and  force  multiplier  needed  for  the  twenty-first  century  battlefield.  To  mitigate 
the  shortcomings  of  currently  fielded  systems,  MALS  planners  use  flat-file  technology 
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that  requires  extensive  resources  and  the  expenditure  of  valuable  man-hours.  The  lack  of 
system  integration  and  the  need  for  a  web-centric  application  was  validated  by  fonnal 
surveys  that  were  distributed  throughout  the  Marine  Corps,  and  identified  as  an  “action- 
item”  from  a  conference  attended  by  key  aviation  logistics  planners  from  the  Marine 
Corps’  operating  forces.  The  purpose  of  this  thesis  was  to  develop  a  web-enabled 
prototype  to  fill  the  current  and  projected  technology  gap  that  was  identified. 

This  thesis  used  the  RAD  methodology  to  develop  the  Marine  Aviation  Planning 
and  Sustainment  System  (MAPSS),  a  prototype  designed  to  optimize  management  and 
decision  support  for  deliberate,  time  sensitive,  and  crisis-action  planning  at  the  tactical- 
level.  Prototyping  was  an  appropriate  system  development  methodology  because  of  the 
current  and  on-going  transformation  of  Marine  Aviation  Logistics;  it  allowed  known 
system  requirements  to  be  designed  and  implemented  with  the  first  iteration,  and  allows 
new  and  unforeseen  requirements  to  be  implemented  in  the  future.  Microsoft  Access 
2003,  Microsoft  Visio  2003,  and  Macromedia  Dreamweaver  MX  2004  were  the  tools 
used  to  develop  the  prototype.  The  back-end  relational  database  was  designed  with 
Microsoft  Access  2003.  The  front-end  web-enabled  interface  was  designed  using 
Macromedia  Dreamweaver  MX  2004.  Microsoft  Visio  2003  was  used  to  create  the 
conceptual  data  and  logical  process  models  for  the  system.  The  first  iteration  of  the 
prototype  was  subjected  to  a  usability  study  conducted  at  the  Naval  Postgraduate  School, 
and  also  tested  by  Operations  Officers  that  were  assigned  to  MALS-11  and  MALS-36, 
both  of  which  provided  valuable  feedback. 

B.  CONCLUSIONS 

MAPSS  is  a  viable  prototype  that  has  the  potential  to  optimize  multi-level 
decision  support  for  deliberate,  time  sensitive,  and  crisis  action  planning  for  aviation 
logistics.  The  MAPSS  prototype  consists  of  over  130  web-pages,  all  consistently 
designed  and  logically  integrated  within  three  system  modules:  CONOPS  Development, 
COA  Development,  and  Operation  Dashboard.  The  navigational  structure  of  the  three 
modules  was  designed  to  be  consistent  with  the  natural  workflow  of  the  current  planning 
and  sustaining  processes  of  MALS.  Furthennore,  the  use  of  templates  and  cascading 
style  sheets  were  instrumental  in  the  development  of  the  unified  “look  and  feel”  of  the 
prototype. 
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The  first  version  of  the  prototype  was  favorably  received  by  both  squadrons  that 
agreed  to  “test-drive”  the  system.  The  most  significant  aspect  of  the  system  was  the  four- 
into-one  system  integration  design;  MAPSS  combined  the  data  sets  from  four  different 
systems  into  one  logically  organized  user  interface.  Another  important  distinction  was 
the  low-bandwidth  design.  The  text-based  system  allows  users  to  quickly  complete 
transactions,  circumventing  the  bandwidth  constraints  that  normally  plague  deployed 
forces.  The  prototype  also  received  positive  feedback  for  its  ease  of  navigation,  COA 
comparison  techniques,  and  use  of  the  stoplight  model  on  the  Operation  Dashboard. 

The  MAPSS  prototype  was  also  subjected  to  a  usability  study,  which  consisted  of 
five  participants  performing  scenario-based  tasks.  The  usability  study  was  an  opportunity 
to  evaluate  the  effectiveness,  efficiency,  and  satisfaction  with  which  specified  users  can 
achieve  specified  goals.  In  short,  it  was  opportunity  to  test  the  prototype  in  a  controlled 
environment,  and  the  results  used  to  improve  the  next  iteration  of  the  prototype.  The 
results  for  system  effectiveness  were  very  encouraging;  all  participants  of  the  study  were 
able  to  successfully  complete  all  scenario-based  tasks.  Moreover,  the  usability  study  was 
completed  with  just  a  1%  system  error  rate;  very  acceptable  for  a  first  version  prototype. 
System  efficiency  was  another  important  aspect  of  the  study.  Collecting  the  time  and 
number  of  mouse-clicks  were  instrumental  in  identifying  three  potential  issues  related  to 
the  navigational  side-bar  located  on  each  main  page  of  the  system.  Lastly,  user 
satisfaction  was  determined  by  a  post-experiment  survey  that  measured  the  level  of 
satisfaction  with  system  functionality  and  usability  features.  The  results  were 
overwhelmingly  positive:  the  average  score  for  system  functionality  was  3.59  and  system 
usability  received  a  score  of  3.40,  both  scores  were  from  a  4.00  rating  scale.  Clearly, 
users  were  “satisfied”  with  the  first  version  of  the  prototype. 

C.  FUTURE  RESEARCH 

There  are  multiple  avenues  of  research  that  can  be  pursued  as  a  result  of  this 
thesis  that  would  contribute  to  the  overarching  goal:  a  fielded  infonnation  management 
system  that  optimizes  decision  support  for  deliberate,  time  sensitive  and  crisis  action 
planning  for  tactical-level  aviation  logistics  forces.  The  most  immediate  opportunity  is  to 
continue  the  evolutionary  process  of  the  prototyping  methodology;  the  current  prototype 

must  be  refined  and  a  second  iteration  developed  and  deployed. 

87 


Although  MAPSS  is  a  viable  concept  and  was  well  received,  there  were  numerous 
issues  identified  that  have  the  potential  to  make  the  system  more  effective  and  user- 
friendly.  The  following  are  some  areas  that  should  be  researched: 

•  Ability  to  assign  multiple  personnel,  repair  parts,  support  equipment  and 
mobile  facilities  to  multiple  COAs  with  one  user  input  transaction.  This  functionality 
would  require  complex  Structured  Query  Language  (SQL)  statements  to  be  coded  for  the 
COA  Development  page. 

•  Ability  for  the  system  to  automatically  generate  a  COA  shell  or  template 
(personnel,  parts,  support  equipment  and  mobile  facilities)  based  on  user  input  of  the 
CONOPS  Development  page.  This  functionality  would  require  a  complex  algorithm  and 
some  statistical  analysis  of  past  operations. 

•  Optimizing  the  user  interface  for  both  1024  x  768  and  1280  x  768 
resolution  monitors  and  designing  a  fourth  module  (System  Administration)  with  future 
prototype  iterations. 

Another  essential  area  that  needs  to  be  addressed  is  the  back-end  data  interface 
with  existing  information  management  systems.  The  current  version  of  MAPSS  (given 
the  scope  of  one  thesis)  admittedly  only  addresses  half  of  the  problem  domain.  This 
thesis  was  primarily  focused  on  how  data  from  existing  systems  could  be  integrated  and 
logically  organized  into  one  user  interface  that  was  conducive  to  AVLOG  planner’s 
needs  and  requirements.  Hence,  future  research  needs  to  address  the  other  half  of  the 
problem  domain:  the  physical  data  link  connection  of  MAPSS  with  the  NALCOMIS, 
MCTFS,  SERMIS,  TBA  and  MDSS-II  back-end  databases.  The  need  to  push  and  pull 
data  from  existing  systems  is  a  basic  system  requirement  for  any  future  AVLOG  decision 
support  system.  The  current  processes  are  time  consuming  and  manually  intensive. 
Planning  logistics  support  and  sustaining  deployed  forces  would  only  be  improved  by  an 
efficient  and  interoperable  four-into-one  web-enabled  user  interface. 

The  last  area  of  research  for  a  system  of  this  nature  is  database  security.  MAPSS 

is  an  operational  planning  system;  hence,  it  inherently  contains  sensitive  information  that 

should  be  protected  against  unauthorized  disclosure.  The  web-centricity  of  the 

application  increases  the  effectiveness  and  convenience,  but  it  equally  increases  the  risks 
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and  vulnerabilities.  Database  security  is  a  never-ending  process,  constantly  requiring  the 
implementation  of  the  latest  tactics  and  techniques  to  safeguard  the  confidentiality, 
integrity,  and  availability  of  an  organization’s  information.  Future  research  in  this  area 
could  include  the  analysis  of  authentication  and  accreditation  techniques  for  DoD  web- 
enabled  databases.  Furthermore,  vulnerability  and  penetration  testing  of  the  current 
MAPSS  database  could  accomplished,  with  the  intent  of  improving  and  strengthening  the 
security  measures  for  future  iterations  of  the  prototype.  The  21st  century  battlefield  will 
require  a  robust  decision  support  system  to  execute  mission  requirements.  Such  a  system 
is  meaningless,  however,  without  equally  robust  information  security  measures. 
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